Difference between revisions of "How to report a bug"

From Wiki [en] OpenMandriva
Jump to: navigation, search
m (Good practices with bug reporting with OpenMandriva)
(My OpenMandriva Lx does not want to start program: - Initial version)
Line 59: Line 59:
  
 
===My OpenMandriva Lx does not want to start program ===
 
===My OpenMandriva Lx does not want to start program ===
What are needed to run program in console, try with gdb or valgrind.
+
 
 +
Mandriva Linux is a collection of software programs that we try to make work as well as possible. It is important to distinguish between console and graphical X-Window applications who provide a graphical user interface.
 +
 
 +
Here is what you can do to check if a graphical application shouldn't start:
 +
 
 +
* Open up a virtual terminal when you are logged into your graphical desktop. You will find this usually in sections like Tools or System tools. In KDE look out for the Konsole terminal emulator and launch that one. In LxQt it should be something like LxQt Terminal.
 +
* Try to launch that application from the command line. If you don't know what to type try to find out the name of the binary you want to start. You can use the package manager to find more about where a program has been installed into. In which directory that is.
 +
* You might also want to try just type the beginning letters of the application (libre for LibreOffice as an example and then press the Tab-key to use the auto-completion feature in the bash shell which is running inside that Terminal you just opened. If that doesn't produce any effect try pressing the Tab-key on your keyboard twice shortly afterwards. You should then be presented with a list of possible matches.
 +
* Execute that command you would like to run. If console output is thrown inside your terminal and you are experiencing crashes please let us know of the issue in our [https://issues.openmandriva.org Bugzilla]. If you get things like core dumped etc. or unexpected errors, do submit these outputs. Ideally you put these in a text file and attach this file to your report using the "Add an Attachment" link in Bugzilla.
 +
* Some times things have already been fixed by our software suppliers and they provide a new version and source code. In that case we can build a package with the new version included. Please see the Package Request section on this page for more.
 +
* If you wish to dig even further, have a look at gdb and valgrind tools but this is very advanced and we do not expect this from you when submitting a bug report to us.
 +
 
  
 
[[QA/Debugging|Debugging Tools and Information]]
 
[[QA/Debugging|Debugging Tools and Information]]

Revision as of 11:52, 7 February 2016

We here try to explain to all OpenMandriva users and contributors how to file a bug-report with the maximum precision in the report. This way developers exactly know what needs to be done to apply fixes to our beloved products.

What are bugs?

A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

Where to report them and how to sign up?

  • Our Bugzilla is located at http://issues.openmandriva.org and you need an account with this offering. Do feel free to sign up for this. It doesn't cost any monthly fees and we don't share your information with third parties. Once the registration is completed and you have confirmed your email address you should be able to login at our Bugzilla site.
  • After having logged in click the file a new bug in the main menu.
  • A form should come up where you can put your information in.

To improve the quality of our upcoming releases we rely on feedback from our users. Our developers will eventually cut out the flaws that are affecting the OpenMandriva distribution which will improve the quality of our distribution which will in turn result in a better user experience with our products. We have set up a Bug-Reporting instance called Bugzilla which is at http://issues.openmandriva.org - We named the subdomain so people can report issues they think that they should be fixed.

If you want to report a bug please use our official bug reporting tool, even if you already reported it by sending and e-mail, IRC or used our forums.

Good practices with bug reporting with OpenMandriva

  • Check if a similar issue has already been reported. This can be done with the search field. Additional options such as advanced search are also available. If you find such as an issue and it isnot confirmed, please do it. This can be done using a short notice like "Confiming in latest Cooker as of 1.January 2016 with all updates applied" and use the drop down-menu to set the issue to confirmed. The reason is that bugs are more interesting to developers and it takes some load of us if you change the status of the bug.
  • One bug, one report: Some people put all of the issues they are facing into one report: Please try to do a separation of problems and report them individually in their own specific reports.
  • Bugzilla is not relly the place to ask for help and general discussion. Use the public forums we provide to discuss issues you are facing, discuss them there and if you agree that it should be reported as a bug, do it!
  • The official language in our Bug Reporting System is English but we don't insist on a specific regional English (like UK-English or American English). We are aware that English is not everyone's mother tongue but we hope you do your best to write reports in the English language. It is the lingua-franca of the business world after all.
  • Make sure the bug is not happening with the upstream project: At OpenMandriva we are doing a Linux-based distribution, a collection of software we receive from other Free and Open Source software projects. Often we complile their source code and make the resulting binaries available on ISO-images that you can burn on a CD, USB-stick etc.
  • Do collaborate with upstream projects as well: We strongly believe that we are a part of the Linux ecosystem as a whole and we want other distributions to benefit from our productions as well.

As the are several projects in the Open Source world we encourage you to submit your contributions, no matter if is just reporting or fixing a typo upstream as well so also Linux distributions benefit at the same time from what you put in.

  • Use a good title which reflects what you are experiencing: Please include what the problem is. Do NOT write the version number of your distribution in the title. Use the selection fields in the bug form

for this. Things like "Problems! I need help!!" do grab attention but waste to much time for developers to identify the particular problem and think about what they can do to fix it.

  • Provide console output if possible: If you have problems starting an application for example and it won't start, please try launching it from the command-line in a terminal emulator. If there is a

resulting output with further information please send this output to us in a text-file. Ideally you put the output in a plain text file and use a plain text editor. For LxQt this might be the leafpad editor, for KDE you might want to try Kate as an editor. Just don't use full fledged office suite document formats (.odt-format in LibreOffice etc.) Developers prefer to receive console output rather than screenshots or photographs that are have been taken with a smartphone camera on your mobile device you might have.

  • Logs are great! We are happy to receive them, ideally in plain text as well but this is fairly standard on Linux system that logs are generated as text files.

The following command might help in that case: journalctl -f -n 1000

  • Try to make sure that you have the latest updates applied. The reason for this is that we don't want you to waste your time to a bugfix which has already been rolled out using our update functionality.
  • Suggestions from users: Getting new ideas and inspiration from other people is always nice but our bug reporting instance of Bugzilla should be on software quality.
  • Try to track down the problem: Things like changing user names from a graphical interface is nice and comfortable but problems might be in the inner workings of the Linux system itself. As we moved to systemd you might want to use things like:
  • Feel free to use our system analytics tool to provide further information about your computer system: omv-bug-report tool

I have a new package request

Yes, let's build packages (which is a lot of fun) and we have a fairly automated process for that so we can supply packages quickly. Please do the following:

  • File an issue at http://issues.openmandriva.org
  • Put Package Request in the title as well as the name of the package you would like to have built, updated, rolled out etc. Also let us know which version number you would like to have
  • Put the URL to the package source, source rpm-URL in the URL field of the form
  • Make a few notes in the description field. I would like to request package XYZ.
  • We will take a look at the project's site and will try to fulfill your request.
  • Keep checking the status of your issue in Bugzilla. When we accept the request, we set it to "ACKED" (Acknowledged) and when building is underway to "IN PROGRESS". Once the package is done, we mark it as "CLOSED/FIXED".


Common cases

Below you can find some instructions of how to properly file a bug when you fall in these common scenarios.

My OpenMandriva Lx distribution does not want to boot in live mode

Description Step by step what do to to collect most information about your system, how to boot in debug mode etc.

My OpenMandriva Lx distribution does not want to boot from grub2 (installed)

Description Step by step how to boot in debug/recovery mode, also what is needed for bug-report like output of journalctl, dmesg...

My OpenMandriva Lx does not start graphical desktop

What files are needed to be attached to bug-report, screenshots etc.

My OpenMandriva Lx does not want to start program

Mandriva Linux is a collection of software programs that we try to make work as well as possible. It is important to distinguish between console and graphical X-Window applications who provide a graphical user interface.

Here is what you can do to check if a graphical application shouldn't start:

  • Open up a virtual terminal when you are logged into your graphical desktop. You will find this usually in sections like Tools or System tools. In KDE look out for the Konsole terminal emulator and launch that one. In LxQt it should be something like LxQt Terminal.
  • Try to launch that application from the command line. If you don't know what to type try to find out the name of the binary you want to start. You can use the package manager to find more about where a program has been installed into. In which directory that is.
  • You might also want to try just type the beginning letters of the application (libre for LibreOffice as an example and then press the Tab-key to use the auto-completion feature in the bash shell which is running inside that Terminal you just opened. If that doesn't produce any effect try pressing the Tab-key on your keyboard twice shortly afterwards. You should then be presented with a list of possible matches.
  • Execute that command you would like to run. If console output is thrown inside your terminal and you are experiencing crashes please let us know of the issue in our Bugzilla. If you get things like core dumped etc. or unexpected errors, do submit these outputs. Ideally you put these in a text file and attach this file to your report using the "Add an Attachment" link in Bugzilla.
  • Some times things have already been fixed by our software suppliers and they provide a new version and source code. In that case we can build a package with the new version included. Please see the Package Request section on this page for more.
  • If you wish to dig even further, have a look at gdb and valgrind tools but this is very advanced and we do not expect this from you when submitting a bug report to us.


Debugging Tools and Information

Further reading