abrt and pk-debuginfo-install

Recently I’ve been looking at the abrt project. It’s looking pretty good so far, with one notable exception: Currently they install the debugging packages using the Fedora script debuginfo-install, and scrape the standard out for errors, and inject to standard in an unconditional ‘Y’ to anything that looks like a question. The script is also used by gdb to ask the user to install certain debuginfo packages. It’s not great form to ask the user to run a random command, when the program is more than capable.

Program received signal SIGINT, Interrupt.
0x00a63422 in __kernel_vsyscall ()
Missing separate debuginfos, use: debuginfo-install DeviceKit-003-1.i586 DeviceKit-power-009-0.74.20090628git.fc11.i586 GConf2-2.26.2-1.fc11.i586

Now, some explaining. Fedora stores debuginfo packages in separate debuginfo repositories. This means the install-debuginfo script has to enable sources, get the deps of the packages to install, and install as many of the debuginfo packages as it can find, and then disable the sources it enabled. This is all horribly Fedora specific, and of course has to be done as root.

[hughsie@hughsie-laptop src]$ debuginfo-install DeviceKit-003-1.i586 DeviceKit-power-009-0.74.20090628git.fc11.i586 GConf2-2.26.2-1.fc11.i586
You must be root to run this command.

For a cool trick, I’ve make a PackageKit version of this script, called pk-install-debuginfo. It does exactly the same thing as the Fedora debuginfo-install script, but runs as the user and uses all the PK methods underneath the hood. So in theory pk-install-debuginfo would run on Kubuntu or on Foresight (or the others too) with a little tweaking.

[hughsie@hughsie-laptop ~]$ pk-debuginfo-install DeviceKit-003-1.i586
1. Getting sources list...OK. Found 10 enabled and 29 disabled sources.
2. Finding debugging sources...OK. Found 4 disabled debuginfo repos.
3. Enabling debugging sources...OK. Enabled 4 debugging sources.
4. Finding debugging packages...OK. Found 1 packages:
5. Finding packages that depend on these packages...OK. No extra packages required.
Found 1 packages to install:
1    DeviceKit-debuginfo-003-1(i586)    fedora-debuginfo
6. Installing packages...OK.
7. Disabling sources previously enabled...OK. Disabled 4 debugging sources.

Except it won’t, as other distros do things differently. I’m guessing some store the debuginfo files in the main repositories (and hence no sources need to be enabled), and some others call the files -dbg rather than -debuginfo. So now I need your help. If your distro does things differently from the Fedora way, please tell me how, and I’ll add support for it in pk-install-debuginfo.

Of course, if the sources are signed and no repos need to be enabled, then things just install without authentication. This is how it’s supposed to work. I’ve also added a man page and I’ll be adding a config file for pk-install-debuginfo soon.

Of course, if you don’t like the idea, just pass –disable-debuginfo-install to the configure script when compiling PackageKit. Comments welcome.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

8 thoughts on “abrt and pk-debuginfo-install”

  2. Actually, why does the crash reporter tool need local debug packages at all? I’m an Ubuntu user, but for their Apport system they also ask users to install debug packages and reproduce the crash… OTOH you can upload a core dump to Launchpad, and some server-side tool will then extract a backtrace from that. Why isn’t this used much more? For the normal user it’s much easier to just upload the core dump right when the crash happens first time, and then don’t worry about it any more.

    I’m wondering: is it too much server load? Or is this due to privacy concerns? Or any other reasons?

    1. What comes to my mind here first, and you mention is as well is the security concerns. Uploading a whole core dump is a horribly wrong idea in vast majority of cases.

  3. PS: of course, local debug packages are still immensily useful for developers; and the Red Hat debuginfo packages with included source code truly rock!

  4. Off Topic:

    Is anyone else seeing horrible Firefox performance scrolling the gnome blogs?

    I’ve got to View->Page Style->No Style to be able to scroll without horrible lag and CPU spikes.

    firefox-3.5-0.20.beta4.fc11.i586

    1. Just thought I’d post a follow-up. Since a the recent update to firefox 3.5 ( and possible other packages ) my performance scrolling the gnome blogs has been fixed. Fedora comes through again ;-)

  6. Mandriva debug repositories are prefixed with “debug_” in their uri (eg: debug_main, debug_contrib, debug_non_free).

    Their names contains the sub string “Debug”.

    Like there is main/release, main/updates, … there is debug_ main/release, debug_ main/updates, …

    Debug packages are suffixed with “-debug”. Eg debug package of the “foobar” package is named “foobar-debug” (really the SRPM name + “-debug”)

Comments are closed.