From Mageia wiki
Jump to: navigation, search
(Category Bug Squad is being moved to Category Bugsquad)
Line 136: Line 136:
 
[[Bug_Squad_Portal|Go to the Bug Squad Portal]]
 
[[Bug_Squad_Portal|Go to the Bug Squad Portal]]
  
[[Category:Bug Squad]]
+
[[Category:Bugsquad]]
 
[[Category:Bugzilla]]
 
[[Category:Bugzilla]]
 
[[Category:Contributors]]
 
[[Category:Contributors]]
 
[[Category:Documentation]]
 
[[Category:Documentation]]
 
[[Category:Howtos]]
 
[[Category:Howtos]]

Revision as of 11:30, 2 August 2021


Drakconf multiflag.png
Other languages
Deutsch ; English ; Français ; Português (Portugal) ; Türkçe ;


Synopsis:
This page will help you to understand what bugs are, when and how they should be reported and what to pay attention to. Effective bug reports are the most likely to be fixed. These guidelines explain how to write such reports.
Warning!
The common language used is English, so please refrain from reporting bugs in other languages. Feel free to ask in the IRC channels or forums if you need someone to help you with this.

Definition

So what are bugs exactly? A bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. But a bug is not restricted to software, bugs can be everywhere, in software, in hardware, in the persons maintaining any of those, even in one's food (pun intended). So basically if there's a reproducible problem, be it documentation, translation, artwork, the websites or infrastructure, maybe even with Mageia.Org itself, one of its contributors or with the organisation of teams, or anything similar can be reported as a bug. Also, package requests are bugs, to give some examples.

Principles

  • Be precise
  • Be clear - explain it so others can understand the bug clearly
  • One bug per report
  • Reproduce the bug - If the bug you want to report cannot be reproduced by your description (on another computer or in a fresh Mageia installation) chances that it will be fixed are much lower - developers need to be able to reproduce bugs to be able to fix them most of the time
    • It's always a good idea to ask in forums or on one of the mailing lists if someone can reproduce the issue at hand or if someone sees that bug too
  • Try to search related bugreports for the software you're reporting a bug, e.g. for KDE at https://bugs.kde.org/ or for systemd at https://bugs.freedesktop.org
    be also sure to simply search for the problem via Google or similar to verify if this is not a known problem
  • No bug is too trivial to report - small bugs may hide bigger bugs
  • Clearly separate fact from speculation
  • Please always prefix calls to programs with LC_ALL=C so that error messages or other output will be shown in English, for example
    Don't run urpmi somepackage, but LC_ALL=C urpmi somepackage
    • Some applications will not start in English when using LC_ALL=C. In that case, try LC_ALL=en_US.UTF-8 or LANGUAGE=C

Preliminaries

  • Make sure you use a supported Mageia version that is fully updated
  • Go to https://bugs.mageia.org and search Bugzilla, to see whether your bug has already been reported.
    • You can use the quick search, by entering some relevant terms
    • Placing the letters ALL as the first term in your search string will return all relevant bug reports including any resolved ones.
    • If "your" bug is already there, you can leave a comment on the report that you can confirm the bug. When you're not sure whether it is the same, ask for help on IRC or in the forums.

Reporting a New Bug

If you have reproduced the bug in a more recent build and no-one else appears to have reported it, then:


  1. Sign in with your account (first you need to create one, check FAQ about Mageia.org user accounts)
  2. Click on File a Bug (if you didn't find the same bug before with the Search field)
  3. Choose "Enter a new bug" you can either take the "guided form" or if you have already done this before, use the default form
  4. Select the product in which you've found the bug, (only available via the expert form). In the guided form "Mageia" is preselected. To report bugs on Mageia websites or infrastructure (like Mageia's Bugzilla or the buildsystem) use the default form (see above)
  5. Enter the Source RPM[1] of the package
  6. Fill out the form. Here is a little help to understanding the field names:

Component: In which sub-part of the software does it exist? This field is required. Click the word "Component" to see a description of each component. If none seems appropriate, select RPM packages.

Version: In which version of the distro does it exist? 1 was the first stable version, 2 is the newest stable version, cauldron is the development version.
If you know the bug exists in two or more versions of Mageia, set it to the highest version and add the lower version(s) on the Whiteboard. Cauldron is higher than "2", so for a bug that is valid for all versions, this would mean:

  • Set version to Cauldron
  • Put MGA1TOO, MGA2TOO on the whiteboard

Hardware Platform: On which architecture does it happen? i586 means 32bit, x86_64 means 64bit, arm means ARM architecture and all means that it happens on all architectures. The latter is the most common case.


Source RPM: This is where you can identify exactly which RPM package is involved in this bug report. For instance, if you know the problem you are having is with the program mysqld, then execute rpm -qif /usr/sbin/mysqld. This will tell you the name and version of the RPM package (i.e. MySQL-5.0.27-1mga1) as well as other information. In particular, you are looking for the "Source RPM" field (i.e. MySQL-5.0.27-1mga1.src.rpm) -- this is the information you should provide here. Alternatively, you may use rpm -qf /usr/sbin/mysqld --qf '%{SOURCERPM}\n' to obtain the information. If you do not know the location of the program in question, use rpm -qf `which mysqld` to obtain it.

URL: URL that demonstrates the problem you are submitting (optional). This may be a forum post where the problem was reported originally, and upstream bug report, or a bug report for another distribution which is about the same problem you're reporting.

Summary: How would you describe the bug, in approximately 60 or fewer characters? A good summary should quickly and uniquely identify a bug report. It should explain the problem, not your suggested solution. Please be descriptive and use lots of keywords.

  • Good example: crash in Evolution while checking for new POP mail
  • Bad example: mail crashed
  • Good example: Cancelling a File Copy dialog crashes File Manager
  • Bad example: Software crashes
  • Bad example: Browser should work with my web site

Details: The details of your problem report, including:

Description of problem: More detailed restatement of the summary. Expand on the Summary. Please be as specific as possible about what is wrong.

  • Bad example: I can't seem to login to the system. Please help!
  • Good example: I'm unable to login to the system via ssh. The /var/log/messages log indicates there is a problem with the pam module pam_ldap, but the /etc/pam.d/system-auth file doesn't contain that module and I'm not using LDAP. I looked at /etc/pam.d/sshd and it does contain that module but I'm not sure how it got there unless it was due to the super-spiffy super-ldap-mojo package I installed yesterday.

Version-Release number of selected component (if applicable):

openldap-2.3.34-5mga1, pam-0.99.7.1-2mga1

How reproducible:

Every time I attempt to login.

Steps to Reproduce: Brief, easy-to-follow steps that will trigger the bug. Include any special setup steps.

  1. ssh user@host
  2. see the rejection


For crashing bugs: Have a look at Debugging software crashes to learn how to produce and provide the required debugging information (backtraces) in the case where software crashes or produces a segmentation fault (segfault)


  • Add an Attachment if it can help (not all your logs, just the log of your issue)

You can look inside the Triage Guide to see whether the more specific information is required for your bug report, which lessens the work of the triage team.

  • Enter the email of the package maintainer[2] in Assign To if you know it (or let triage team add it)


Double-check your report for errors and omissions, then press "Commit". Your bug report will now be in the Bugzilla database.

[1], [2]: rpm -qi package will give you a lot of information about a package.

Parts of this page have been taken from https://landfill.bugzilla.org/bugzilla-3.6-branch/page.cgi?id=bug-writing.html

How to file a package request

This is similar to filing a bug, but there are some differences in the needed information.

  • Go to https://bugs.mageia.org
  • Do a quicksearch "ALL <packagename>", of course replace "<packagename>" with the real name of the package
    • If someone already filed a request, add a comment to it that you would like to see the package in Mageia, too
    • If the request was closed as WONTFIX, that was probably because the project is dead upstream. In that case, an alternative Mageia package will usually be named.
    • If you didn't find anything with the quicksearch, go on with the next step:
  • choose File a Bug
  • choose product Mageia
  • (Component:) choose "New RPM package request"
  • (Version:) choose "Cauldron"
  • (Hardware Platform:) choose "All"
  • (Source RPM:) do not add a link here. If you know the name the SRPM should get, then please add that name. Leave it empty if you do not know.
  • (URL:http://) give the upstream link to the package
  • (Summary) please give "the package name", "a short summary of the programs purpose"

Example: vagrant, a tool to build virtualized environments with VirtualBox

    • please use only lower case (small) letters in the package names, that will make it easier to check once in a while whether we already have them.
  • (Details) tell why you think the software is great and what you need it for.
  • (Severity) set this field to "Enhancement"
  • submit the report.

Go to the Bug Squad Portal