or deprecated/hide DrKonqi in deufalt and use abrt

Upstream is planning to add this support to Dr. Konqui, I'm not sure about timeframe. See http://gkiagia.wordpress.com/2009/08/19/installing-debug-symbol-packages-from-drkonqi/

Another possibility is to hack Abrt to support KDE needs. It's quite extensive system so it should be possible to make it behave like Dr. Konqui.

I'll tag this as FutureFeature as we really want this behaviour. But I can't promise anything right now as there's more important work on our TODO list.

Going to rebase this to Rawhide to give us time to work on it.

-- 
Steven M. Parrish - KDE Triage Master
                  - PackageKit Triager
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I would like to ask the DrKonqi use KpackageKit(or something else with gui) if this is possible? for now uses something in the console (probably debuginfo-install).

Yes, it uses the script upstream ships for Fedora which uses debuginfo-install. I agree Konsole is not a great user interface.

I was looking at abrt-debuginfo-install instead of upstream's shipped  debuginfo-install but it's not usable for us - it accepts core file and tries to extract build ids, dr. konqui provides libraries with missing debuginfos only. It's possible to replace shipped script with Qt GUI version using packagekit-qt.

Indeed, we could easily replace the script by a compiled binary. (The expected file name can also be changed so we don't have to ship a binary with a ".sh" extension, there's a CMake option provided for that.)

The question is, do we really need to reinvent the wheel using our own UI around packagekit-qt? Couldn't kpackagekit be reused?

What we should also do is patch out the fake progress dialog as the GUI can display a real one, but that's cosmetic and trivial. Implementing the UI is the actual work.

it would be better to use code from abrt-debuginfo-install - abrt doesn't use debuginfo-install but it downloads it by yumdownloader and unpacks to debug info cache dir (so debuginfo are not installed at all). They don't solve cleaning cache directory but there's possibility that right debug infos are already installed there and abrt even tries to download missing debuginfos from koji (I don't know if this code is already implemented).

> abrt doesn't use debuginfo-install but it downloads it by yumdownloader and
> unpacks to debug info cache dir (so debuginfo are not installed at all).

Ugh, WTF, that's completely broken and stupid. RPM exists for a reason. Now we can't even just rpm -e all the -debuginfo packages to clean up. :-/

IMHO abrt needs to be fixed to use RPM properly, not DrKonqi changed to use the same cache.

And BTW, I think we should not ship ABRT on the KDE spin (it was a mistake to do so on F12).

I've just experienced gwenview crash, DrKonqi popped up with unusable backtrace, so that I've tried to click to install debuginfo ... now I'm stuck with a window that has something like a progress bar where a blue rectangle goes from left to right and right to left infinitely ...

it seems that drkonqi tried to invoke debuginfo-install:

29784 pts/16   Ss+    0:00  \_ /bin/sh -c echo $$ > /tmp/drkonqi-fifo-29767; su -c "debuginfo-install  kdegraphics kdelibs qt "; exit_status=$?; sleep 1; rm /tmp/drkon
29787 pts/16   S+     0:00      \_ su -c debuginfo-install  kdegraphics kdelibs qt 

... but it forgot to ask for the root password

the password is supposed to be prompted for in a konsole/terminal window (which is where the debuginfo-install process runs)