Nota: La página original es más nueva que esta traducción.

Información para desarrolladores sobre cómo manipular fallos utilizando la interfaz de correo electrónico.

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 dos 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.

Órdenes disponibles en el servidor de correo «control»

General	Versionado	Duplicados	Varios
reassign (reasignar) severity (gravedad) tags (etiquetas) retitle (retitulación) submitter (remitente) affects (afecta) summary (resumen) outlook (panorama)	found (encontrado) \| notfound(no encontrado) fixed (arreglado) \| notfixed(no arreglado) reopen (reabierto)	merge (fusionar) \| unmerge(desunir) forcemerge (fusión forzada) clone (clonar)	thanks (gracias) # forwarded (reenvío) \| notforwarded(sin reenvío) owner (propietario) \| noowner(sin propietario) block (bloqueo) \| unblock(desbloqueo) archive (archivar) \| unarchive(sacar del archivo) user (usuario) \| usertag (etiqueta de usuario) \| usercategory (categoría de usuario

reassign número_de_fallo paquete [ versión ]

Registra que el fallo #número_de_fallo pertenece al paquete. Puede usarse para establecer el paquete si el usuario lo olvidó en la pseudo-cabecera, 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 número_de_fallo [ dirección_del_originador | = | ! ]

Reabre el #número_de_fallo (y limpia la lista de versiones arregladas para el fallo) en caso de que estuviera cerrado.

Por omisión, 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; tenga en cuenta 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úmero_de_fallo [ versión ]

Registra que #número_de_fallo se ha encontrado en la versión dada en versión del paquete al que se asignó. versión puede ser una versión totalmente cualificada, con el formato nombre_paquete_fuente/versión.

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. versión puede ser una versión totalmente cualificada, con el formato nombre_paquete_fuente/versión.

Esta orden sólo hará que un fallo como no arreglado si no se especifica una versión, o si la versión que está marcada es igual o mayor a la versión más alta marcada 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úmero_de_fallo versión

Borra el registro de #número_de_fallo que se encontró en la versión dada del paquete al que está asignado. versión puede ser una versión totalmente cualificada, con el formato nombre_paquete_fuente/versión.

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úmero_de_fallo versión

Indica que el fallo #número_de_fallo 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úmero_de_fallo-done para cerrar un fallo y marcarlo como arreglado en una versión particular.

notfixed número_de_fallo versión

Elimina el registro de que el fallo #número_de_fallo está arreglado en la versión versión. versión puede ser una versión totalmente cualificada, con el formato nombre_paquete_fuente/versión.

Esta orden es equivalente a found seguida de notfound. La orden found elimina el fallo en una versión particular, y el notfound elimina el found. La diferencia es que no se reabre el fallo si la versión de found es mayor que cualquiera de las versiones de fixed. Está pensando para arreglar errores en la indicación de cuándo se arregló una errata. En la mayoría de los casos querrá utilizar found, no notfixed.

submitter número_de_fallo 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úmero_de_fallo dirección

Indica que número_de_fallo ha sido informado al mantenedor oficial en dirección. En sí, esto no reenvía el informe. Se puede usar para cambiar una dirección forwarded-to incorrecta, o para registrar una nueva para un fallo del que no se había indicado que fue reenviado. El valor de dirección debería ser habitualmente una URI o una dirección de correo. Utilice URIs siempre que sea posible para permitir el uso de herramientas que permiten consultar los sistemas de seguimiento de erratas (como bugzilla) para conocer el estado de un fallo.

Ejemplo de uso:

      forwarded 12345 http://bugz.illa.foo/cgi/54321

notforwarded número_de_fallo

Elimina cualquier registro de que número_de_fallo haya sido reenviado a algún mantenedor oficial. Si este fallo no tenía registros que indicasen tal reenvío, entonces no sucederá nada.

retitle número_de_fallo nuevo título

Cambia el título del informe de fallo por el que se específica (por omisión se toma la cabecera de correo Asunto) del mensaje original).

También cambiará el título de todos aquellos fallos con los que número_de_fallo esté fusionado (merged).

severity número_de_fallo gravedad

Establece el nivel de gravedad del informe de fallo #número_de_fallo. No se enviará notificación alguna al usuario que informó de él.

Las posibles gravedades son critical, grave, serious, important, normal, minor, wishlist.

Si desea saber sus significados, sírvase consultar la documentación general para desarrolladores sobre el sistema de fallos.

affects número_de_fallo [ + | - | = ] paquete [ paquete ... ]

Indica que un fallo afecta a otro paquete. En el caso de que número_de_fallo cause un problema en paquete aunque el fallo está de hecho presente en el paquete al que está asignado. Esto hace que la errata se muestre por omisión en la lista de fallos de paquete. Esto debería utilizarse cuando la errata es suficientemente importante para causar que múltiples informes de error enviados por los usuarios se asociaran al paquete incorrecto. = indica que afecta a los paquetes indicados y es la acción por omisión si no se indican paquetes; - quita los paquetes indicados de la lista de afectados, + añade los paquetes indicados a la lista de afectados y es la acción por omisión si se indican paquetes.

summary número_de_fallo [número_de_mensaje | texto_de_resumen]

Selecciona el mensaje a utilizar como resumen del fallo. Se trata el primer párrafo que no forme parte de las pseudo-cabeceras o no sea una orden de control y se utiliza como resumen del fallo. Este resumen se muestra al principio de la página de informe de fallos. Esto es útil en los casos en los que el informe original no describe correctamente los problemas o cuando el fallo tiene demasiados mensajes y se hace difícil identificar el problema existente.

Si no se proporciona número_de_mensaje, se borra el resumen. número_de_mensaje es el número de mensaje tal y como se lista en la salida del script CGI bugreport; si el numero_de_mensaje es 0, se usa el mensaje actual (el mensaje enviado a control@bus.debian.org el cual contiene la orden de control summary).

Si el número_de_mensaje no es numérico y es una cadena no vacía, se asume que es el texto a usar como resumen.

outlook número_de_fallo [número_de_mensaje | texto_de_panorama]

Selecciona el mensaje a utilizar como el panorama usado para solucionar un fallo (o el estado actual de la solución de un fallo). El primer párrafo que no forme parte de las pseudo-cabeceras o no sea una orden de control se utiliza como panorama del fallo, el panorama del fallo se muestra en la parte superior de la página del reporte de fallo. Esto es útil para coordinar con otros que estén solucionando este fallo (por ejemplo, en una reunión de corrección de fallos).

Si no se indica un número_de_mensaje, se borra el panorama. número_de_mensaje es el número de mensaje tal y como se lista en la salida del script CGI bugreport; si el número_de_mensaje es 0, se usa el mensaje actual (el mensaje enviado a control@bus.debian.org el cual contiene la orden de control outlook).

Si el número_de_mensaje no es numérico y es una cadena no vacía, se asume que es el texto a usar como panorama.

clone número_de_fallo 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úmero_de_fallo número_de_fallo ...

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úmero_de_fallo número_de_fallo ...

Fusiona a la fuerza dos o más informes de fallos. Todos los valores definidos para el primer fallo (que deben ser iguales en una fusión normal) se asignan a los fallos listados a continuación. 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.

Tenga en cuenta que esto hace posible cerrar fallos fusionándolos. Es su responsabilidad avisar a los remitentes con un mensaje de cierre apropiado si lo hace así.

unmerge número_de_fallo

Desconecta 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úmero_de_fallo [ + | - | = ] etiqueta [ etiqueta ...]

Añade a las etiquetas del informe de fallo #número_de_fallo la etiqueta etiqueta. No se enviará notificación alguna al usuario que informó del fallo. Si la acción es + se añade cada etiqueta listada a continuación, si la acción es - se eliminan todas las etiqueta listadas a continuación, y si es = se indica que se deben fijar los valores que se indican en este momento. La acción por omisión 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

        # quitar la etiqueta 'moreinfo' y añadir la etiqueta 'patch'
        tags 123456 - moreinfo + patch

Entre las etiquetas disponibles en este momento se incluyen 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 .

Consulte la documentación general para desarrolladores sobre el sistema de fallos si desea conocer sus significados.

block número_de_fallo by fallo ...

Anota de que la errata del primer fallo está bloqueado por el otro.

unblock número_de_fallo by fallo ...

Anota que el arreglo del primer fallo ya no está bloqueado por el otro.

close número_de_fallo [ versión arreglada ] (obsoleto)

Cierra el informe de fallo #número_de_fallo.

Se envía una notificación al usuario que informó del fallo, pero (en contraste a enviar número_de_fallo-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 anotará que el fallo se arregló en esa versión del paquete.

package [ nombre_del_paquete ... ]

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úmero_de_fallo dirección | !

Hace que dirección sea el «dueño» de #número_de_fallo. 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úmero_de_fallo

Olvida cualquier hecho que apunte a que el fallo tenga un dueño diferente a su mantenedor habitual. Si el fallo no tiene dueño asignado, no hará nada.

archive número_de_fallo

Archiva un fallo que se archivó previamente si el fallo cumple todos los requerimientos para archivarse, ignorando el tiempo transcurrido.

unarchive número_de_fallo

Saca del archivo un fallo que se archivó previamente. Generalmente cuando se saca del archivo, la orden debería ir acompañado de reopen y found/fixed según sea apropiado. Los fallos que se han sacado del archivo se pueden volver a archivar usando archive, asumiendo que se cumplen todos los requisitos para ser archivados excepto el de tiempo transcurrido. No se debe usar unarchive para hacer cambios triviales a fallos archivados, como cambiar el remitente del fallo; el propósito principal de unarchive es permitir la reapertura de fallos que han sido archivados sin la intervencíón de los administradores del sistema de seguimiento de fallos.

#...

Comentario de una línea. El símbolo # 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.

quit

stop

thank

thanks

thankyou

thank you

--

En una sola línea, en mayúsculas o minúsculas, posiblemente seguida de espacio en blanco, le indica al servidor de control que debe parar el proceso del mensaje; el resto puede incluir explicaciones, firmas, o cualquier otra cosa, pero nada de esto lo detectará el servidor de control.

Otras páginas del sistema de seguimiento de fallos (BTS en inglés):

Debian BTS administrators <owner@bugs.debian.org>