For reporting bugs in KDE at bugzilla.opensuse.org, 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.opensuse.org, please consider the following:
Which repos need testing?
KDE:Release:XY is important for shipping only updates to the regular distro with the corresponding KDE version, KDE:Distro:Factory becomes more important the closer a new openSUSE release comes. KDE:Unstable:SC 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, but you can use it for testing upstream KDE and making bug reports at bugs.kde.org.
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.opensuse.org 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.opensuse.org) 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 kdepim4-debuginfo, libkde4-debuginfo, kdelibs4-debuginfo, kdebase4-debuginfo kdebase4-workspace-debuginfo, libqt4-x11-debuginfo and libqt4-debuginfo is all that is required though.
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
To report bugs against openSUSE Factory (not if you use a released openSUSE version plus KDE:/Distro:/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.