diff options
Diffstat (limited to 'markup/pod/live-manual/media/text/es/project_bugs.ssi')
-rw-r--r-- | markup/pod/live-manual/media/text/es/project_bugs.ssi | 221 |
1 files changed, 221 insertions, 0 deletions
diff --git a/markup/pod/live-manual/media/text/es/project_bugs.ssi b/markup/pod/live-manual/media/text/es/project_bugs.ssi new file mode 100644 index 0000000..b3ceb93 --- /dev/null +++ b/markup/pod/live-manual/media/text/es/project_bugs.ssi @@ -0,0 +1,221 @@ +:B~ Cómo informar acerca de errores. + +1~bugs Informes de errores. + +Los sistemas en vivo están lejos de ser perfectos, pero queremos que sean lo +más perfectos posible - con su ayuda. No dudar en informar de un error. Es +mejor llenar un informe dos veces que no hacerlo nunca. Sin embargo, este +capítulo incluye recomendaciones sobre cómo presentar buenos informes de +errores. + +Para los impacientes: + +_* Primero, siempre se debe comprobar el estado actualizado de la imagen en +busca de problemas conocidos en la página web http://live-systems.org/. + +_* Antes de presentar un informe de errores, se debe intentar reproducir el +error con las *{versiones más recientes}* de live-build, live-boot, +live-config y live-tools de la rama de que se está utilizando (como la +última versión 4.x de live-build si se utiliza live-build 4). + +_* Se debe intentar proporcionar *{una información tan específica como sea +posible}* acerca del error. Esto incluye (al menos) la versión de +live-build, live-boot, live-config y live-tools utilizada y la distribución +del sistema en vivo que se está construyendo. + +2~ Problemas conocidos + +Debido a que Debian *{testing}* y Debian *{unstable}* están cambiando +continuamente, no siempre es posible crear un sistema con éxito cuando se +especifica cualquiera de estas dos versiones como distribución objetivo. + +% FIXME: + +Si esto causa mucha dificultad, no se debe crear un sistema basado en +*{testing}* o *{unstable}*, sino que debe utilizarse *{stable}*. live-build +siempre crea, por defecto, la versión *{stable}* . + +Los problemas detectados se especifican en la sección 'status' de la página +web http://live-systems.org/. + +Está fuera del alcance de este manual enseñar cómo identificar y solucionar +correctamente problemas de los paquetes de las distribuciones en desarrollo, +sin embargo, hay dos cosas que siempre se puede intentar: Si se detecta un +error de creación cuando la distribución de destino es *{testing}*, se debe +intentar con *{unstable}*. Si *{unstable}* no funciona bien, se debe volver +a *{testing}* haciendo un pin con la nueva versión del paquete de +*{unstable}* (véase {APT pinning}#apt-pinning para más detalles). + +2~ Reconstruir desde cero + +Para asegurarse de que un error en particular no es causado por crear el +sistema basándose en los datos de un sistema anterior, se debe reconstruir +el sistema en vivo entero, desde el principio y comprobar si el error es +reproducible. + +2~ Utilizar paquetes actualizados + +Utilizar paquetes obsoletos puede causar problemas importantes al tratar de +reproducir (y en última instancia, solucionar) el problema. Hay que +asegurarse de que el sistema de construcción está actualizado y cualquier +paquete que se incluya en la imagen esté también al día . + +2~collect-information Recopilar información + +Se debe proporcionar información suficiente con el informe. Como mínimo, la +versión exacta de live-build donde se encuentra el error y los pasos para +reproducirlo. Se debe utilizar el sentido común e incluir cualquier +información pertinente si se cree que podría ayudar a resolver el problema. + +Para sacar el máximo provecho de un informe de errores, se requerirá al +menos la siguiente información: + +_* Arquitectura del sistema anfitrión + +_* Distribución del sistema anfitrión. + +_* La versión de live-build del sistema anfitrión. + +_* Versión de /{debootstrap}/ en el sistema anfitrión. + +_* Arquitectura del sistema en vivo. + +_* Distribución del sistema en vivo. + +_* Versión de live-boot en el sistema en vivo. + +_* Versión de live-config en el sistema en vivo. + +_* Versión de live-tools en el sistema en vivo. + +Se puede generar un log del proceso de creación mediante el comando +#{tee}#. Se recomienda hacer esto de forma automática con un script +#{auto/build}# (ver {Gestionar una configuración}#managing-a-configuration +para más detalles). + +code{ + + # lb build 2>&1 | tee build.log + +}code + +En el momento del arranque, live-boot y live-config guardan sus logs en +#{/var/log/live/}#. Comprobar si hay algún mensaje de error en estos +ficheros. + +Además, para descartar otros errores, siempre es una buena idea comprimir en +un .tar el directorio #{config/}# y subirlo a algún lugar, para que el +equipo de Debian Live pueda reproducir el error (*{No}* se debe enviar como +documento adjunto a la lista de correo). Si esto es difícil (por ejemplo, +debido a su tamaño) se puede utilizar la salida del comando #{lb config +--dump}# que produce un resumen del árbol de configuración (es decir, listas +de archivos de los subdirectorios de #{config /}# pero no los incluye). + +Hay que recordar que los informes a enviar se deben hacer en ingles, por lo +que para generar los logs en este idioma se debe utilizar la variante local +English, p.ej. ejecutar los comandos de live-build o cualquier otro +precedidos de #{LC_ALL=C}# o #{LC_ALL=en_US}#. + +2~ Aislar el fallo si es posible + +Si es posible, aislar el caso del fallo al menor cambio posible que lo +produzca. No siempre es fácil hacer esto, así que si no se consigue para el +informe, no hay que preocuparse. Sin embargo, si se planea el ciclo de +desarrollo bién, con conjuntos de cambios lo bastante pequeños por +iteración, puede ser posible aislar el problema mediante la construcción de +una simple «base» de configuración que se ajuste a la configuración actual +deseada, más el conjunto del cambio que falla añadido. Si resulta difícil +determinar que cambios produjeron el error, puede ser que se haya incluido +demasiado en cada conjunto de cambios y se deba desarrollar en incrementos +más pequeños. + +2~ Utilizar el paquete correcto sobre el que informar del error + +Si no se sabe qué componente es responsable del error o si el error es un +error general relativo a los sistemas en vivo, se puede rellenar un informe +de errores contra el pseudo-paquete debian-live. + +Sin embargo, se agradece si se intenta limitar la búsqueda a donde aparece +el error. + +3~ En la preinstalación (bootstrap) en tiempo de creación. + +live-build crea primero un sistema Debian básico con /{debootstrap}/. Si un +error aparece en este momento, se debe comprobar si está relacionado con un +paquete específico de Debian (es lo más probable), o si está relacionado con +la herramienta de preinstalación en sí. + +En ambos casos, esto no es un error en el sistema en vivo, sino de Debian en +sí mismo, por lo cual nosotros probablemente no podamos solucionarlo +directamente. Informar del error sobre la herramienta de preinstalación o el +paquete que falla. + +3~ Mientras se instalan paquetes en tiempo de creación. + +live-build instala paquetes adicionales del archivo de Debian que pueden +fallar en función de la distribución Debian utilizada y del estado diario +del archivo Debian. Se debe comprobar si el error es reproducible en un +sistema Debian normal, si el fallo aparece en esta etapa. + +Si este es el caso, esto no es un error en el sistema en vivo, sino de +Debian - se debe informar sobre el paquete que falla. Se puede obtener más +información ejecutando /{debootstrap}/ de forma separada del sistema de +creación en vivo o ejecutando #{lb bootstrap --debug}#. + +Además, si se está utilizando una réplica local y/o cualquier tipo de proxy +y se experimenta un problema, se debe intentar reproducir siempre +preinstalando desde una réplica oficial. + +3~ En tiempo de arranque + +Si la imagen no arranca, se debería informar a la lista de correo, junto con +la información solicitada en {Recopilar información}#collect-information. No +hay que olvidar mencionar, cómo y cuándo la imagen falla, si es utilizando +virtualización o hardware real. Si se está utilizando una tecnología de +virtualización de cualquier tipo, se debe probar la imagen en hardware real +antes de informar de un error. Proporcionar una captura de pantalla del +error también es muy útil. + +3~ En tiempo de ejecución + +Si un paquete se ha instalado correctamente, pero falla cuando se ejecuta el +sistema en vivo, esto es probablemente un error en el sistema en vivo. Sin +embargo: + +2~ Hacer la investigación + +Antes de presentar el informe de errores, buscar en la web el mensaje de +error en particular o el síntoma que se está percibiendo. Como es muy poco +probable que sea la única persona que tiene ese problema en concreto, +siempre existe la posibilidad de que se haya discutido en otras partes y +exista una posible solución, parche o se haya propuesto una alternativa. + +Se debe prestar especial atención a la lista de correo del sistema en vivo, +así como a su página web, ya que seguramente tienen la información más +actualizada. Si esa información existe, se debe incluir una referencia a +ella en el informe de errores. + +Además, se debe comprobar las listas de errores actuales de live-build, +live-boot, live-config y live-tools y verificar si se ha informado ya de +algo similar. + +2~ Dónde informar de los fallos + +El ${project} realiza un seguimiento de todos los errores en el sistema de +seguimiento de errores de Debian (BTS). Para obtener información sobre cómo +utilizar el sistema, consultar https://bugs.debian.org/. También se puede +enviar los errores mediante el comando #{reportbug}# del paquete con el +mismo nombre. + +En general, se debe informar sobre los errores en tiempo de creación contra +el paquete live-build. De los fallos en tiempo de arranque contra el paquete +live-boot, y de los errores en tiempo de ejecución contra el paquete +live-config. Si no se está seguro de qué paquete es el adecuado o se +necesita más ayuda antes de presentar un informe de errores, lo mejor es +enviar un informe contra el pseudo-paquete debian-live. Nosotros nos +encargaremos de reasignarlo donde sea apropiado. + +Hay que tener en cuenta que los errores que se encuentran en las +distribuciones derivadas de Debian (como Ubuntu y otras) *{no}* deben +enviarse al BTS de Debian a menos que también se puedan reproducir en un +sistema Debian usando paquetes oficiales de Debian. |