Cómo presentar un error

Mantenemos una lista de problemas comunes. Compruebe primero este sitio para ver si ya se ha informado de su problema — y si existe una solución.

Como de los errores se informa y son corregidos, los desarrolladores coleccionan un conjunto de soluciones y periódicamente lanzan versiones mejoradas de su software. De este modo, antes de informar de una cuestión es útil comprobar si usted está utilizando la última versión de un software. La manera más sencilla de obtener la última versión de software en Fedora es actualizar regularmente su sistema. Los usuarios de Gnome/KDE y otros entornos de escritorio pueden usar sus aplicaciones predeterminadas para hacer esto. Estas comprueban periódicamente si hay actualizaciones y lo notifican a los usuarios. También puede usar el administrador de paquetes predeterminado dnf para comprobar y actualizar su sistema. Solo lo pueden hacer los usuarios con privilegios de administrador:

Si está usando la última versión del software disponible en Fedora, es posible que el error no haya sido reportado todavía o que haya sido reportado pero todavía no esté solucionado. Por lo tanto, es útil buscar en la lista de los errores ya reportados antes de publicar un nuevo reporte. La aplicaciónhttps://packages.fedoraproject.org/[ Web Fedora Packages] proporciona un enlace a los errores abiertos para un paquete. Hay también un atajo conveniente que puede ser usado.

Aquí, package name debe ser el nombre formal del paquete.

Si ya se ha presentado un informe de error que describe el problema, debería proporcionar cualquier información extra que pueda tener. Si no tiene nada más que añadir al informe, debería poner "CC" (carbon-copy) para usted en el informe para recibir cualquier actualización. Esto se puede hacer pulsando en el botón "Save changes" cuando se ha confirmado la opción "Add me to CC list" como se muestra abajo:

Los errores se rellenan en Bugzilla y usted debe tener una cuenta Bugzilla para presentar errores e interactuar con ellos. Una vez que ha creado una cuenta en Bugzilla, también puede acceder usando su cuenta Fedora. Para usar su cuenta FAS para acceder a Bugzilla, necesita o usar la misma dirección de correo electrónico en FAS y en Bugzilla o, si son diferentes, establecer la dirección de correo electrónico de Bugzilla explícitamente en su perfil FAS.

El rastreador de errores solo enviará notificaciones de correo electrónico sobre los errores en los que esté involucrado un usuario. No se enviarán otros correos electrónicos.

Si un reporte de error para un problema concreto no se ha presentado aún, usted debe presentar uno nuevo. La manera más fácil de presentar un nuevo reporte es usando el desplegable "File a new bug" (Presentar un nuevo error) desde la barra del lado derecho en la aplicación Web Paquetes Fedora.

Esto le dirige a una plantilla de reporte de nuevo error en el trazador de errores. La imagen de abajo presenta una plantilla de nuevo error:

Es necesario completar los siguientes campos:

Descripción del problema:

Explicar el problema en más detalle.

Número de Versión-Lanzamiento del componente seleccionado (si es aplicable):

Aquí se debe especificar la versión del paquete. Una vez que se sabe el nombre del paquete, se puede obtener la versión usando el comando rpm:

Por ejemplo:

How reproducible:

How often is the issue observed? Usually, a good answer to this field is one of:

Issues that occur always are easiest for developers to diagnose, since they may also be able to replicate it on their machines to collect more information. If an issue only happens sometimes, developers must spend more time and effort to understand what causes the problem. If an issue was only observed once, it is even harder to debug.

Steps to Reproduce:

These enable other users to verify the bug, and they also inform the developers of what specific steps cause the issue. It makes it much easier for them to look at the source code and pick out the bits that may be faulty.

Actual results:

What is observed when the issue occurs?

Expected results:

What does the user expect that should happen if the software behaved correctly?

Additional info:

Any additional information that may be useful to the maintainer should be added here.

After a bug has been filed, you should keep an eye out for any updates. The bug status workflow documentation describes the different statuses a bug may have. An e-mail notification of any new comments to the report will be sent to everyone involved in the bug report---the reporter, other users, and the maintainer. Often, maintainers will comment with queries to gather more information on the issue. Sometimes other users that experience the same issue may also add more information.

A well reported bug will often be fixed, and the maintainer will make an improved version of the software available to Fedora users. Bodhi will add a comment to the report when this happens. You can help the maintainer by confirming if the improved version works better in the Bodhi.

Once the improved version of the software has passed the QA process, the bug will automatically be closed. Congratulations!

If you have experienced a program crash, it will almost certainly be necessary to include a stack trace with your bug report. Crashes are often difficult to reproduce and even more difficult to fix, so the more information you can provide, the better. You will probably need to install -debuginfo RPMs so your stack trace will have useful debugging symbols. See the following pages for more information:

If you are having trouble with a graphical user interface (GUI), it often helps to include a screenshot or a screencast showing the bug in action. This helps developers find the exact place in the code which is causing the bug, and helps communicate what is going wrong when it is difficult to reproduce (for example, machine-specific layout problems).

A strong indication of a hardware-specific bug is that other people with different hardware should be able to reproduce the bug, but can’t. They also usually involve code that specifically interacts with a peripheral, such a webcam, video card, printer, or sound card (so for instance, it is uncommon for bugs affecting the user interface of a word processor or desktop calculator to be hardware-specific).

If you suspect your bug has something to do with the specific hardware you have, it will be necessary to identify the hardware so targeted action can be taken.

PCI and PCI-E devices found by the kernel can be listed with lspci.

USB devices found by the kernel can be listed with lsusb.

You may also find mention of specific devices or drivers in your system logs (run journalctl).

We pay special attention to security-sensitive bugs. Read the Reporting a Security Vulnerability] page to understand the special process of opening a security bug.