|
|
|
|
|
|
|
|
|
|
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:
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.
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 para más detalles).
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.
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 .
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:
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 para más detalles).
# lb build 2>&1 | tee build.log
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.
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.
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.
live-build crea primero un sistema Debian básico con debootstrap o cdebootstrap. Puede fallar dependiendo de la herramienta usada en la preinstalación y de la distribución Debian empleada. 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.
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.
Si la imagen no arranca, se debería informar a la lista de correo, junto con la información solicitada en Recopilar información. 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.
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:
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.
El Live Systems 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.