1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
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.
|
