aboutsummaryrefslogtreecommitdiffhomepage
path: root/markup/pod/live-manual/media/text/es/project_bugs.ssi
diff options
context:
space:
mode:
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.ssi221
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.