Fallos para construir desde la fuente, Fallos para instalar

Esta página describe la política para los paquetes que ya no se construyen o instalan y necesitan atención del desarrollador.

La planificación de la mayoría de los lanzamientos de Fedora incluyen una reconstrucción masiva (por ejemplo Fedora 27 Mass Rebuild, Fedora 28 Mass Rebuild) para actualizar los paquetes con nuevas funciones del compilador, empaquetamiento, indicadores de construcción, etc. Esto sirve como una oportunidad conveniente para detectar todos los paquetes que ya no se compilan correctamente.

Glosario

FTBFS

Fallo Al Compilar Desde Fuentes

FTI

Fallo al Instalar (usualmente debido a dependencias rotas)

Desinstalación de paquete para defectos de estado largo FTBFS y FTI

Paquetes los cuales falla al compilar o falla al instalar será huérfano y/o retirado tras un periodo de tiempo.

  1. Si un paquete falla al compilar desde fuentes o falla al instalar cualquier parte interesada puede informar un fallo en Bugzilla bloqueando un seguimiento FTBFS/FTI, proporcionando información sobre el fallo.

    • Un defecto sobre fallo de compilación necesita bloquear el seguimiento FTBFS para la liberación apropiada, p.ej. F30FTBFS para Fedora 30, consulte el listado a continuación.

    • Un defecto sobre fallo de instalación necesita bloquear el seguimiento FTI para la publicación apropiada, p.ej. F30FailsToInstall para Fedora 30, consulte el listado debajo.

    • Un defecto puede bloquear múltiples seguimientos si se conviene. Informadores están motivados para buscar primero duplicados.

  2. Los mantenedores cualquiera repararía y cerraría el defecto o reconoce que están trabajando en una solución poniendo el estado a ASIGNADO.

  3. Si permanece un fallo FTBFS o FTI dentro del estado NUEVO para al menos 1 semana, cualquier persona interesada puede establecer una pregunta NEEDINFO al mantenedor para responder.

  4. Si el fallo permanece en estado NUEVO por al menos otras 3 semanas después el NEEDINFO (= al menos para 4 semanas en total), cualquier parte concerniente puede enviar otro comentario añadiendo el mantenedor para responder.

  5. Si el defecto permanece en el estado NUEVO por al menos otras 4 semanas después el segundo comentario (= al menos 8 semanas en total), el paquete será huérfano. Huérfano puede ser solicitado por medio de un problema releng.

  6. Lo normal Proceso de Paquete Huérfano será seguido por los paquetes huérfanos en esta manera, abandonando a su retirada si nadie lo adopta.

  7. Cca seis semanas antes de Fedora N ramificación masiba, paquete que no eran correctamente recompilados al menos en Fedora N-2 están recogidos y semanalmente recordados son enviado a mantenedores afectados y la lista de correo de desarrollo de Fedora.

  8. CCa una semana antes de la Fadora M ramificación masiva^. paquetes que no eran correctamente compilados al menos en Fedora N-2 serán retirados asumiendo que ha sido al menos avisados 5 veces en el listado de correo de desarrollo. El estado de defecto no ha tomado efecto en esta retirada. Esto se puede solicitar a través de un problema de releng.

  9. Una semana antes la planificación congelado bela, cualquier paquete que tenga abierto defectos FTI en el estado NUEVO por al menos 8 semana con al menos 2 recordatorios de comentarios serán retirados desde la publicación relevante y cuero crudo (en adición a ser huérfano). (Ticket releng para esto necesita estar abierto al menos una semana antes de congelar, pero puede ser abierto más pronto.)

  10. El punto anterior repite para el congelado final.

    Ejemplo de retirada FTBFS

    Pronto antes de ramificación Fedora 31, los paquetes que fueron la última recompilación correcta en Fedora 28 (o incluso más pronto) serán retirados. En el tiempo de Fedora 31 GA, todos los paquetes fueron recompilados en un Fedora actualmente soportado (en al menos Fedora 29).

(Efectivamente, paquetes que fallan al compilar serán retirados tras 14 semanas o antes si no hay respuesta de mantenedor y el paquete está huérfano, o tras 13 meses si el mantenedor responde pero el paquete no es reparado.)

Cuando releng realiza la recompilación masiva, releng apre los fallos FTBFS para cualquiera de los paquetes los cuales fallan al compilar. Cualquiera puede enviar los recuerdos semanalmente y los paquetes solicitados a ser huérfanos/retirados; en otras palabras, el procedimiento puede ser aplicado manualmente. En cualquier punto, releng puede automatizar cualesguieran pasos mencionados antes, pero esto no es requerido.

Cualquier tiempo un ticket relang está abierto, cruce referencia desde el informe de defecto.

Paquetes de ejemplo desde esta normativa

Seguimiento de defectos

¿Qué hacer si obtiene un defecto de FTBFS?

  • Lea las bitácoras. Cada fallo de FTBFS tendría adjuntadas las bitácoras de compilación.

  • Si la compilación de su paquete falla debido a un defecto en su paquete:

    1. Solucione los problemas no cubiertos y efectúe los cambios.

    2. Construye el paquete. El paquete reparado aterrizará en ‘rawhide’ (agujero en crudo), generalmente el siguiente día. Si la rama ya ha sucedido, además repara la combilación en la rama realizada.

    3. Si la compilación es correcta, cierre el defecto (bug, bicho,…​) como CERRADO: RAWHIDE, e incluya el número de la versión del paquete dentro del campo Fixed In Version. Aquí está una plantilla de línea de comando para usuario experto: bugzilla modify --close RAWHIDE <bug-number> --comment 'Built successfully in rawhide' -F <package-nevr>

    4. Si la ramificación ya sucedió, pero bodhi no ha sido activado aún, además compilar el paquete en ramificación.

    5. Si bodhi ya ha sido activado para ramificación, además realiza una actualización. Una actualización sería hecha incluso si ramificación ya ha sido liberada.

  • Si la compilación de su paquete falla debido a un defecto en otro paquete (tal como un defecto de compilador o dependencia ausente):

    1. Encuentre un defecto existente para ese paquete describiendo el problema. Establezca su defecto a "Depende en" que otro defecto. No cambie el componente de su defecto para el otro paquete, u obtendrá más defectos de FTBFS creados contra usted.

    2. Cuando ese otro defecto está cerrado, obtendrá un correo-e desde bugzilla como usual. Recompile su paquete utilizando una compilación desde cero, para verificar sus compilaciones limpias de nuevo. Proceda de acuerdo a puntos 2-5 de arriba.

  • Si el paquete no es más largo útil para el proyecto Fedora, sería retirado.

    Consulte Proceso de Retirada de Paquete.

En todos los casos, si cierra un fallo FTBFS como un duplicado de otro fallo, haga el otro fallo para bloquear el derecho FTBFS de seguimiento de fallos. Esta manera el fallo izquierdo abierto apelará en los informes FTBFS apropiadamente.

Consulte además

Want to help? Learn how to contribute to Fedora Docs ›