Bugs:KDE

From openSUSE

This article is under review! The contents are currently being evaluated and edited by User:Jonathan_R. Others should not make major changes in the meantime. Thanks for the cooperation.

This article will help you in filing bug reports for KDE.

KDE Bugreports

General

For reporting bugs in KDE at bugzilla.novell.com, it is helpful to know which packages are installed. Some people have only the plain openSUSE release packages installed (sometimes with and sometimes without online updates) and others have upgraded from the KDE3 or KDE4 repositories at opensuse.org. Some even run some experimental packages that might induce further bugs.

More information: Debugging KDE

Before you report bugs

Not all bugs you find belong into Novell's bugzilla. So before you report anything to bugzilla.novell.com, please consider the following:

Which repos need testing?

KDE4:STABLE is important, KDE4:Factory becomes more important the closer a new openSUSE release comes. UNSTABLE is completely useless for the openSUSE team, since it is neither part of any released openSUSE version, nor being worked on for a future release. Same for not yet released versions of applications. The latter is usually indicated by a svn12345 as part of the package-name.

Report at bugzilla.novell.com or bugs.kde.org?

With their limited resources the openSUSE team has to focus on STABLE and openSUSE-specific bugs/features. Further, they cannot be experts for every single application, so the maintainer of an application at bugs.kde.org is likely to have more knowledge and can fix things quicker.

Thus every non-openSUSE-specific bug, i.e. bugs that are valid for other distros as well, should have a report at bugs.kde.org. In case it is a really important feature, like e.g. bluetooth support not working at all, or a really important bug, which might already be fixed upstream, then it does make sense to file it downstream (at bugzilla.novell.com) too and add the upstream bug report into the URL field. That way the openSUSE team can keep track of showstoppers before a release and crucial fixes after a release.

If your upstream report is set to "fixed" and includes a patch, you should set your opensuse report from "upstream" to "assigned" for the openSUSE developers to decide whether to release the fix as official update or not.

Enhancements almost always are something to report upstream. If you feel there is something crucial that is in upstream trunk, i.e. not released yet but already existent, or lacking upstream but really important, then please discuss that issue on the opensuse-kde mailinglist or put it on the agenda for the bi-weekly IRC meeting.

Useful Crash Reports

Crash backtraces should always get reported with installed -debuginfo packages. If the backtrace contains a text like " This backtrace appears to be of no use.", then you're either missing the debuginfo package or don't have the correct version installed. You can install them the moment you see dr. konqi come up - before you click in the "backtrace" tab, but you have to install them from the same installation medium you use (beta2 debuginfos do not fit to beta1 executables). Usually kdepim3-debuginfo, kdelibs3-debuginfo, kdebase3-debuginfo and qt3-debuginfo is all that is required though.

Each source package generates one debuginfo, but may be split into many binary RPMs. This makes it harder to know which debuginfo to install. If you're not sure which debuginfo you need

• Identify the process that crashed. Eg. /usr/bin/kwin
• Find out which RPM it is packaged in: "rpm -qf /usr/bin/kwin" shows kwin is packaged in kde4-kwin
• Find out which source package the binary RPM was generated from: "rpm -qi kde4-kwin | grep Source\ RPM" shows kwin's sources are in kdebase4-workspace
• Install the corresponding debuginfo package. In this case, kdebase4-workspace-debuginfo

If you are doing a lot of testing or bug triage, it helps to have the base KDE platform debuginfos installed already. They are located in the same repo as the non-debuginfo KDE4 packages you installed. These are

• libqt4-debuginfo
• kdelibs4-debuginfo
• kdepimlibs4-debuginfo
• kdebase4-runtime-debuginfo
• kdebase4-workspace-debuginfo

To report bugs against openSUSE Factory (not if you use a released openSUSE version plus KDE4:/Factory:/) or openSUSE beta versions you will need both the factory repo and its debuginfo repo configured - Betas don't have debuginfo packages. Install the corresponding package from Factory and its debuginfo and debugsource sub-packages and get a good backtrace with line numbers.

More information: KDE Crash Reporting Guide

Specific Hints and tricks

About the only useful logfile is $HOME/.xsession-errors - only for kdm/login issues there are some more, namely /var/log/messages, /var/log/kdm.log, /var/log/Xorg.0.log.

Debugging of kio_slaves (any problem with a protocol within konqueror for instance) is a bit more tricky. A description for this can be found here.

If you attach a gdb to a running process, remember that if the process has "[kdeinit]" in the name, the right executable is not e.g. dcopserver but kdeinit.

Debugging Network Management

See our Network Management troubleshooting guide at KDE UserBase for tips on how to diagnose a problem with your networking.