From Mageia wiki
Jump to: navigation, search
Drakconf multiflag.png
Other languages

Deutsch ; English ; Français


It requires improvements. If you want to improve it, simply log in and click on the Edit tab.

Please remove this {{Draft}} template, when you're sure the page is complete and correct.

This page is a guide to triaging bugs reported on Mageia. It is intended principally for members of the Bug Squad and should serve as a guide for new members and an aide memoire for experienced members.

Still to be done

  • add more information about install (which package to choose)
  • add info about infrastructure and website bugs
  • and about requests to remove a package from cauldron
  • make sentences easier to understand, where possible
  • add empty lines where needed

First things first, is it a duplicate?

The first thing to consider is whether the bug is a duplicate of a previously-opened report. You may simply remember from previous work that you have seen a similar bug report. Otherwise, it's recommended to search the entire database using keywords related to the bug that are most likely to return duplicate bugs.

When searching bugzilla it's recommended to use the "Advanced Search" interface; it might look too complex in the beginning until you get used to it but it's a very powerful search tool, where you can search for chunks of crash backtraces, some unique words/strings pertaining to a bug report.

Consider the relationships between components when searching. For instance, if someone reports a crash in a GNOME application, consider that the underlying problem may in fact lie in, for instance, the GTK+ or Pango libraries. Search in these areas.

In case the bug is a duplicate that got solved, don't forget to include the RESOLVED bugs in your search.

Put "ALL" before your search string when you're sure a "quick search" is enough. For instance, if someone files a bug against dansguardian, searching for

 ALL dansguardian

will also show the already resolved bugs.

You can also get the most reported bugs in the last 7 days in the duplicates page of the bugzilla. (or since the beginning of the distribution if you play a little with the settings).

OK, it is a duplicate, what next?

If the bug is a duplicate of a previous report, you should set the bug to the RESOLVED DUPLICATE status with the appropriate bug number. This will usually be the only action required. If the fact that the bug is a duplicate may not be obvious to the reporter without further explanation - for instance, the report is for a crash in a certain program, but the problem actually lies in an underlying library and has been previously reported - you may wish to explain this in a comment to ensure the reporter understands the resolution.

The bug affects two different releases! What now?

Identical bugs filed on different releases should not be closed as duplicates. For instance, if a bug is reported on Cauldron and then subsequently on a stable release, do not close the second report as a duplicate of the first. The reason for this is that resolution of a bug in one distribution does not imply a resolution of the same bug in another distribution, so under the current Bugzilla system, having separate reports for each distribution is the best way to handle such situations. You have to also set blockers and depends properly: cauldron bug blocks other mageia versions bugs.

Please note!
Instead of having separate bug reports for separate releases, we have started to put MGA5TOO on the whiteboard of cauldron bug reports that are also valid for Mageia 5. When the bug is fixed in cauldron, version can be set to 5 and MGA5TOO can be removed from the whiteboard.

Should the issue be covered by the Mageia bug process?

Firstly, consider the definition of a bug

from the Bug policy: "A bug is defined as a case in which a component of a Mageia Linux distribution (or other product covered by Bugzilla, such as a Mageia website(s)) fails to fulfil its intended function." Consider whether the issue reported qualifies under these terms. Note that there is an exception for valid enhancement requests - see the Bug Policy for more details.

An example of a report which would fail the test, is a request for an additional feature in a piece of software which is not maintained by the Mageia development team or a report which is obviously attributed not to a Mageia component but to user error or to a hardware issue specific to the reporter's machine.

If a bug fails the test, the bug report should get a comment explaining why this isn't a Mageia bug and its status should be changed to RESOLVED INVALID.

The same should be done when the failing software isn't an official Mageia package. That isn't always obvious, anyone can build a package which looks like a Mageia package, but was not built on our servers and certainly not signed by us.

This can be checked by putting a space and the package name after the following command:

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SIGPGP:pgpsig}\n'

like is done below for translate-shell:

[m@c ~]$ rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SIGPGP:pgpsig}\n' translate-shell
translate-shell- RSA/SHA256, zo 28 jul 2019 11:53:22 CEST, Key ID b742fa8b80420f66
[m@c ~]$

If that command returns "Key ID b742fa8b80420f66", like in the example above, then it's good: that package, on the same computer, was signed by Mageia.

Especially when a bug cannot be confirmed, it is a good idea to ask the reporter to check for installed third-party packages. Obtaining a list of installed packages, that were not signed by the Mageia organization, can be done with (entire command on one single line):

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SIGPGP:pgpsig}\n' | grep -v b742fa8b80420f66

Sometimes a bug report is a support issue rather than a genuine bug, or the reporter is incapable of describing the bug well of of providing all needed information. In these cases, it is wise to suggest the reporter to ask for help in our forums or on It is often better to leave such reports open for a while and to close them (as RESOLVED-OLD) when a few weeks later no information is added that suggests there's a real bug, or when the report keeps lacking needed information. Officially, those reports should get the RESOLVED-INVALID status, but that can cause massive feelings of shame for some inexperienced users.

Secondly, should the bug be handled elsewhere?

(usually by the developers of the software in question). For instance, a bug caused by a fundamental flaw in the software's source code should be resolved by the upstream development team, even though it could theoretically be fixed by a Mageia developer with a patch. Resolving such issues upstream reduces the burden of patch maintenance on the Mageia development team (and the associated risk of error and instability).

If a stack trace is provided in the bug report, consider searching the upstream bug management system (for instance, GNOME or KDE Bugzilla) to see if a bug with a similar stack trace has previously been reported.

When the problem lies in the software itself, set the UPSTREAM keyword

When the code is hardly or not maintained upstream you may wish to consider it appropriate for the Mageia process as there is a higher likelihood that the Mageia development team will be able to resolve it than that of the inactive upstream maintainers will.

If the upstream development team is maintaining the software well, you should post a comment explaining your reasoning and requesting that the reporter of the bug send a report to the appropriate place (depending on the package, this may be another bug tracking system, a forum or a mailing list). Ideally, include a link to the appropriate place in your comment, for the reporter's convenience. Ask the reporter to post a comment once he has made his upstream report, linking to the report. Once the reporter has done this, you should add the link to the upstream report in the URL field, before assigning it to the maintainer. Once the bug has been fixed by the upstream development team, the fix can then be incorporated with an update to the Mageia package. Of course, our developer is free to patch the package before upstream comes with a fix.

Thirdly, is the bug filed on a supported release?

If the Mageia release on which the bug is filed is no longer supported, add the NEEDINFO keyword and ask the reporter for testing if it's still valid with the latest cauldron or any still supported products. Ping him if he doesn't reply within two weeks. If he doesn't reply within another two weeks, you can set it to the RESOLVED OLD resolution with a comment explaining the reason. This doesn't apply to enhancement requests as most of them should be set to Cauldron version (modify version field if needed).

Is all necessary information there?

If the issue passes the past tests, it is an issue requiring action by the maintainer, and should eventually be assigned to the maintainer for action. However, you should not do this until the information provided on the issue is as complete as possible.

The general rule is that a bug report should contain at least enough information to make the problem simpler for the maintainer to reproduce and understand. Valuable information includes, but is not limited to:

  • Exact version of the package(s) being used
  • Architecture (i586 or x86-64)
  • Precise steps to reproduce the problem ("gedit crashes" is bad; "gedit crashes when I launch it from the menu, type 'abracadabra' and click on Print" is good)
  • Error messages displayed by the application, or on a console when the application is run from the console
  • Hardware information where this may be a factor - IDE / SCSI / SATA hard disks, USB storage devices, lsusb, lspci, 'lspcidrake -v' ...etc output...
  • Information on the operating environment: what desktop / shell is in use, is the app being run remotely, what other packages which may affect operation of the app are in use, what configuration settings have been changed... etc

A very good way to check whether all necessary information has been provided is to see whether you can reproduce the issue yourself using the information provided in the bug report. Triage team members are advised to keep copies of all currently supported Mageia releases available to help with this. You may want to consider using VirtualBox, VMware, qemu... etc for this purpose.

If sufficient information has not yet been provided, you should add the NEEDINFO keyword to the bug, and add a comment explaining to the reporter what further information is required and - if necessary - how to obtain it. Ping him if he doesn't reply within two weeks. If he still doesn't reply within another two weeks, you can set it to the RESOLVED INVALID resolution with a comment explaining the reason and, ideally, inviting the reporter to reopen the bug report when he supplies the needed information.

Special cases of specific information required

Here are some specific types of bug for which certain types of information will always be required:

Installer-related bugs

Traditional installer

For bugs related to the traditional installer (not installing from a Live CD/DVD), the reporter should provide the file /root/drakx/report.bug.xz as an attachment. An easy way for doing this is ask the reporter to switch to console 2 (by pressing "Ctrl-Alt-F2") during installation after the bug occurs, put a floppy in floppy drive or plug a USB key/stick and type


then press Enter. It will put report.bug on the floppy/key. If the file is too large to attach, then please compress it with xz: xz report.bug and attach the resulting report.bug.xz.

Please note!

If the bug command fails, try again with e.g (if your USB-key is on /dev/sdb):

 bug /dev/sdb1

Adjust the command if needed. You can find, by first running

whether your USB key is on e.g. "/dev/sdb", "/dev/sdc" or "/dev/sdd", etc.

Traditional installer bugs are assigned to the Mageia tools maintainers.

Please note!
At the moment this is written (around 4 beta2 release), for traditional installer upgrades, the /root/drakx/report.bug.xz is of the original install, not of the upgrade. However, /root/drakx/report.bug is of the upgrade. If it is still like that when you read this, then, of course, the last file needs to be compressed and attached.

Live installs

For bugs related to installing from a live CD/DVD after having booted it in Live mode, as root do

 journalctl -a > journalctl-a.txt

before rebooting after install and attach journalctl-a.txt to the bug report. If the file is very large (it probably is), then compress it first.

Hardware detection issues, hardware not supported

If a piece of hardware is detected wrongly or does not seem to be supported at all, the output is required of the command

lspcidrake -v

For USB devices, ask the reporter to install usbutils and then use


If not supported at all, it would also help to know if the reporter is aware of a driver that could potentially support the device.

If there are problems with pluggable hardware which does not work correctly or is not recognized properly/at all, the needed information can be shown via the following procedure: Open a terminal, as root run the following command:

journalctl --lines=20 2>&1 | tee output.txt

and let the reporter attach the file output.txt. This applies to all hardware which is connected to the computer when it is already running. If 20 lines doesn't seem to be enough, then do

journalctl -f 2>&1 | tee output.txt

first and let it run until after the device is plugged in.

Slow boot up

Ask for boot.svg that is the result of running systemd-analyze plot > boot.svg in a konsole or terminal
and also for journal.txt that is the result of running, as root journalctl -ab > journal.txt.

X server crashes at startup

It's not uncommon that the X server crashes at startup, in this case, the reporter should be asked to attach /var/log/Xorg.0.log (copying it before restarting X, or /var/log/Xorg.0.log.old after reconfiguring and restarting X) to the bug report.

If you don't have Xorg logs there, then try (as root): journalctl -b -e /bin/Xorg

System not booting due to wrong menu.lst file

You have to ask reporter to attach /boot/grub/menu.lst file and proper menu.lst if possible. Also, to know more about the partition table, reporter should provide the output of

fdisk -l /dev/sd[a-z]

Printer problems


If there are problems with pluggable hardware which does not work correctly or is not recognized properly/at all, the needed information can be shown via the following procedure: Open a terminal before you plug in the printer, as root run the following command:

journalctl -f 2>&1 | tee output.txt

until a few minutes after you plug it in. Then stop the command with "Ctrl"+"C" and attach the file output.txt to the bug report. This applies to all hardware which is connected to the computer when it is already running.

Additionally always ask how the printer is connected to the PC, f.ex. via USB, parallel port, some sort of USB-parallel converter or even anything else (directly connected via ethernet or wireless, in a network via a print-server ...)

Also maybe triager should look upstream if and to what extent the printer is supported and what driver should be used:

all other issues

Ask for the output of

 rpm -qa cups

and of

 systemctl status cups.service cups.socket -al -n50

and for attachment of

  • /etc/cups/printers.conf
  • /var/log/cups/error_log

Also forward to e.g. to enable cups debug logging and/or gather cups logs via journalctl.

Scanner problems

The following output has to be provided in addition of general outputs:



scanimage -L

Both should be run as root to find all attached scanners (as for some devices/drivers, without changing udev rules or adding the normal user to some system groups like lpadmin to give him correct permissions to use the scanner as normal user, the scanner won't show when those commands are run by a normal user)

initrd-related bugs

initrd-related bugs can be easily mistaken for kernel bugs, so examine the report carefully to correctly identify them. If a bug is initrd-related, the package field should be set to


Fedora page about dracut.

Sound problems

Please click the link and read Colin's suggestions on how to debug sound problems

Networking issues

They can be caused by drivers or configuration problems, so you should ask for

  • journalctl.txt that results from, as root, running: journalctl -b > journalctl.txt
  • dmesg.txt that results from running dmesg > /tmp/dmesg.txt that could show some issues with involved kernel modules.
  • ip route show displays the contents of the kernel's routing tables
  • lspcidrake -v output should be asked too, of course.

when the issue is related to wireless connections, the output is needed of the following 3 commands as root:

  • iwconfig
  • iwlist scan
  • iw dev wlp5s0 scan (change "wlp5s0" to whatever that should be for your wlan card, if needed)

Note for triagers: general linux support for wireless devices can be looked up at or at

Also, if a driver is supported by ndiswrapper, ask for

  • ndiswrapper -l output,

and with pcmcia cards, use

  • lspcmcia

Suspend/Hibernate issues

Always ask for dmesg output after resuming if possible (as above ask the reported to attach dmesg.txt that results from running

dmesg > /tmp/dmesg.txt

At first, we need to know if it's caused by X or not, for that, please ask user to turn X off

service dm stop

login as root and run


If it works, it could be a X problem, then, ask reporter for /var/log/Xorg.0.log, /etc/X11/xorg.conf and

lspcidrake -v

output. If it still fails, ask reporter for trying to suspend/hibernate running

echo mem|disk > /sys/power/state

Useful links

Thinkpad specific:

Plymouth problems

  • Plymouth can be disabled by simply appending
    to the kernel command line.
  • Boot in verbose mode, remove the "splash=silent" or "splash" and "quiet" arguments if they appear.

Samba issues

Usually, /var/log/samba contents are useful for trying to solve samba problems, so it's recommended to ask the user to attach it to the bug report.


Usually, the reporter will need to install additional debug packages for getting useful crash backtraces. He should first read this debugging software crashes howto about getting a useful crash backtrace.

Drakxtools Crashes

For Drakxtools crashes you should ask the user to follow these steps (posted by Thierry Vignaud in an old bug report, then updated by triage team):

  • make sure gdb is installed
  • install the glib2.0-debug, glibc-debug, gtk+2.0-debug, perl-Gtk2-debug & perl-debug packages from the "Core Release Debug" and "Core Updates Debug" media. They aren't enabled by default so the user will have to enable them before:
    • start, as root:
      then activate "Core Release Debug" and "Core Updates Debug" (unless you're using cauldron: then only "Core Release Debug" is needed)
    • alternatively this can be done via command line:
      urpmi.update --no-ignore -v "Core Release Debug"; urpmi.update --no-ignore -v "Core Updates Debug"
      then update them
      urpmi.update "Core Release Debug" ; urpmi.update "Core Updates Debug"
    • then install the debug packages:
      urpmi glib2.0-debug glibc-debug gtk+2.0-debug perl-Gtk2-debug perl-debug
  • run the following command in a terminal:
    gdb -q --args perl /usr/bin/<application name>
  • then type run and press Enter
  • When the application crashes, type bt and press Enter
  • attach the resulting stack trace to the bug report

Perl - CPAN issues

If the user is trying to upgrade cpan modules using "cpan" the bug should be closed as INVALID because it is not the official way of doing it, since we are providing cpan modules as packages in the official repositories; for more info read Jerome Quelin's comment in this bug report

Set the product priority, severity and component fields

It is your responsibility as a triage team member to set the product, priority, severity and component fields appropriately.

Product is simply the product line in which a bug falls. The majority of bugs will use Mageia.

The options are usually self-explanatory.


  • The release_blocker priority is only relevant to bugs filed on Cauldron or beta releases, and should only be used for issues which are sufficiently critical that it would severely impair the overall quality of a release if it were made available without the issue being resolved.
  • The high priority should be used for issues which are sufficiently critical that resolving them should take priority over resolving other issues, but which do not meet the criteria for release_blocker
  • The low priority should be used for bugs which are sufficiently trivial and/or limited in impact that resolving other issues should take precedence.
  • The normal priority should be used for all other issues.

Try to prevent untriaged bugs still assigned to Triage Team from being set as release_blocker except when they are really really severe.


  • The critical severity should be used for bugs which render a package essentially unusable (for instance, crashes which would affect the majority of uses of a package, or total inability to install or run the package).
  • The major severity should be used for issues which render a significant feature of the package unusable, or which render the package generally unstable.
  • The minor severity should be used for issues which have only a limited impact on the usability of a package or which will only affect a small minority of users or use cases.
  • The normal severity should be used for all other issues.
  • the enhancement severity, see below for details.

You should also set the RPM Package field where it has not been filled out by the reporter, and where you know what it should be set to. This field can be changed on the right of the bug page.

For Component

  • Backports: Requests for package backport (new version) on stable releases.
  • Installer: Bug reports about Mageia drakx traditional installation (the installer used on the DVD and the Dual ISO's), for the LiveCD installer bugs, use RPM package and add draklive-installer in the installer field.
  • New RPM package request: Bugs for all wanted software (allowed to include in the distribution), one bug per software, to keep the bugs lists clear, help packager and the QA.
  • RPM package: Bugs about all Mageia RPMs (official repository, we don't support third party ones)
  • Release (media or process): Bugs related to problems with the medias provided to install Mageia (mirrors, CD, DVD, ...)
(include grub/gfxboot/syslinux bugs in the isos itself)
  • Security: Security issues (CVE) in Mageia RPMs

Accept the bug and ensure it is correctly assigned

If the bug has made it this far, you can now accept the bug and may add the Triaged keyword. You can also post a comment in the bug report conveying this, e.g. "Assigning to the maintainer". The maintainer can be a person or a team .

It's important to check that the bug report is assigned to the correct maintainer. In most cases the assignment will be correct, i.e. Bugzilla queries the maintainers database and fills the bug assignee ("Assigned To") field automatically based on the package in the "RPM Package" field, but sometimes the Bugzilla maintainer database is incorrect and a bug will be assigned to the wrong person, so this is something to check in every bug report.

If you suspect it may be wrong, check the last few changelog entries for the package. If you are not sure to whom the bug should be assigned, make a best guess, favouring maintainers who are quick to respond to Bugzilla issues.

Finding out about package maintainers
  • The Mageia maintainers database, change rpm which you want to search (we have also a maintainers text page or a list of the committers on each package)
    • Here you'll have to query using the name of SRPM (source RPM), you can find out it out by using these commands:
      • assuming you have that package installed on your system:
        rpm -q --qf '%{SOURCERPM}\n' <package-name>
      • if the package isn't installed you can use urpmq, which will query the urpmi database and should work whether the package is installed or not (using rpm directly when the package is already installed on your system saves you the time (and bandwidth) of downloading the urpmi synthesis files from the online repos):
        urpmq --sourcerpm <package-name>
  • A contributor Website that use the same api as the greasemonkey script.
It show you the list of commiter when there is no maintainer. Also it works also for both RPMs and SRPMs.
  • Sophie
    • You can use the web interface of Sophie to find all sorts of info about rpm packages, including the maintainer of a package
    • If you're familiar with using IRC you can query the Sophie bot directly, look at our Sophie page for more info on how to use the bot on IRC. Using the Sophie bot on IRC is the fastest way to get info about any package so it may be a good idea to learn how to use it.
  • On some IRC channel you can also found [mbot, using ",maint <package>" will returns the same info as the contrib website.


When a certain package has more than one bug report opened against it, it becomes convenient to track all those reports in one single bug. This can be done by opening a bug report and making it "Depend" by putting <the numbers of all the bug reports opened against that package> in the "Depends on" field in Bugzilla. This way when the status of one of those issues is changed the tracker bug report is changed too, this helps in seeing the big picture about the bugs in a certain package (ideally this happens for core/important packages).

How make a tracker ?

  • add [TRACKER] in the summary and in the keyword
  • in this tracker:
    • one bug tracker for the needed implementation
    • one bug for track the bug in/of the implementation
  • don't add enhancement request in a blocker bug
  • don't mix technical with 'physical' bug (artwork/oxygen theme)

List of TRACKER bugs

Enhancement requests

Valid enhancement requests are requests to do with the packaging of a product, or requests for improvements in the code of applications maintained by the Mageia development team. To handle enhancement requests, check whether the report is a duplicate, then check whether the request is comprehensible as written. If not, set the report to NEEDINFO and ask the reporter to clarify. Once the report is sufficiently comprehensible, set the severity to enhancement and the priority to normal and assign the bug to the package maintainer.

On the other hand, if it's an enhancement request to be done directly by upstream, you have to close the bug as INVALID and ask user to report directly to them

Most of the requests will be only solved in cauldron for future Mageia releases (like installer related requests), then, you should try to set version to cauldron most of the times, except bugs requesting, for example, a package backport.

New package requests

  • Check that the package requests complies to
  • Check that the software is free software that we can add to the distribution.
  • Optionally, add packagers, or groups of packagers, that you know might be interested in CC; for example, the KDE maintainers group for a KDE application, or a packager that likes gaming for a new game package.
  • Assign to all packagers collectively (this is the convention):, with the following comment:
 Assigning this package request to all packagers collectively.
On a voluntary basis, one of them might, if there are no license or other legal issues, want to integrate it to the distribution and maintain it for bug and security fixes.
You might also want to join the packager team to maintain this piece of software: see


  • FOR_ERRATA7 : needs to be added to the Mageia 7 Errata page.
  • IN_ERRATA7 : has been added to the Mageia 7 Errata page.
  • FOR_RELNOTES7: to be added to the Mageia 7 Release Notes page.
  • IN_RELNOTES7: has been added to the Mageia 7 Release Notes page.
  • FOR_ERRATA6 : needs to be added to the Mageia 6 Errata page.
  • IN_ERRATA6 : has been added to the Mageia 6 Errata page.
  • check : for bug to close
  • cauldron : for package requests, when the package already exists in cauldron - also for when the cauldron version of a package is requested to be backported for stable
  • MGA5TOO : (for bugs that are filed against cauldron, but exist in Mageia 5, too)
  • only_in:MGA5 or only_in:MGA5,MGA6 : bug reports that are valid only for (a) given stable release(s) but are either fixed or not relevant in cauldron. This information helps when EOL is reached, to know we can close those bugs without retargeting them at a higher release.
    • (MGA5) : for installer bugs, to show that they were still valid for Mageia 5 final
  • 3<$step_of_the_dev> : maybe that will help to keep the errata up-to-date, to ask other people to confirm or invalidate bugs, have a list of the 'new' bugs since the 3rd release and why no found other applications?
  • OK : For the assignee to put on the whiteboard when he accepts the assignment, but can't set status too ASSIGNED
  • LibOUpdate : to have a list of recent bugs of libreoffice (which is currently 'outdated')
  • start7 : for *drak* bugs that have an available patch: apply and risk breaking everything right after Mga6 release, when Mga7 cauldron is opened.

QA Team's Whiteboard strings

See the List of whiteboard keywords used by the QA Team

Obsolete Whiteboard strings

  • Mdv (for package requests, when the package exists in Mandriva) (obsolete)
  • X (for packages not found in Mdv 2010.2) (obsolete)

Powerful comment

Need discuss

What must we do with:

  • How are we going to get packagers to fix bugs in unmaintained packages, when there are available patches?

Common Upstream bug trackers

Go to the Bug Squad Portal