abrt detected a crash on my compiz. When I want to report it, it says that I should run debuginfo-install compiz. I did, but when I refresh it, it says again that I should run debuginfo-install compiz and does not report the bug. Note that abrt successfully reported a kernel crash for me. I use: abrt-desktop-1.0.0-1.fc12.x86_64 abrt-addon-python-1.0.0-1.fc12.x86_64 abrt-plugin-logger-1.0.0-1.fc12.x86_64 abrt-addon-kerneloops-1.0.0-1.fc12.x86_64 abrt-libs-1.0.0-1.fc12.x86_64 abrt-addon-ccpp-1.0.0-1.fc12.x86_64 abrt-plugin-sqlite3-1.0.0-1.fc12.x86_64 abrt-plugin-kerneloopsreporter-1.0.0-1.fc12.x86_64 abrt-plugin-bugzilla-1.0.0-1.fc12.x86_64 abrt-gui-1.0.0-1.fc12.x86_64 abrt-1.0.0-1.fc12.x86_64 Best, Adrin.
The suggestion is right, but both ABRT and debuginfo-install script fails to install desired debuginfo so the backtrace is just full of "No symbol table found" and thus not very usable for developer. Do you have compiz from oficial Fedora repository? Jirka
Yes I installed compiz from fedora repos. Another point is that the yum command ran by abrt has this switch: --enablerepo='*debuginfo*' which enables also rawhide-debuginfo repository. Don't you think that this repo should be excluded by default? Also this yum command is ran as root. I can be run with current user which is more secure and also which is not blocked when another installation or update is in process with user root. Best, Adrin.
ABRT downloads matching $package-debuginfo to your $package; so, if you installed package or two from Rawhide to F-12, it always finds correct -debuginfos via N-V-R either from stable repo, or rawhide. If I am not mistaken.
ABRT doesn't care about N-V-R, it uses build-ids to determine required pacakges, but it's just implementation detail. The rawhide repository could (or should) be probably disabled, because ABRT from F12 will ignore the rawhide packages anyway, because they aren't signed. And you're right, that the yum command can be run as user running the client, but it won't avoid the locking, as the yum.lock is not per user, but per system. Jirka
I disagree with you about yum.lock Jirka, just test it. Yum ran by a normal user does not check that lock while trying to find some packages or so. I tested it myself. Adrin.
You're probably right, there is no need for locking if yum is run by non-root as it can't change anything, but then yumdownloader. We will change it. Thanks, Jirka
When we run yum --enablerepo=*debuginfo* --quiet provides /path/to/debuginfo (see /usr/bin/abrt-debuginfo-install), yum might download new filelists from repositories if local copies are too old. I imagine this requires taking the lock. (BTW, this is *the* operation which takes a lot of time and results in user frustration, I have no idea how to avoid that)
if you run yum with a normal user, it downloads repo data in a user accessible directory as it has not permission to change /var/cache/yum directory. So it does not need to take the lock.
I just checked - we run abrt-debuginfo-install as root. We start it from daemon, not from GUI.
I know that you run it as root, but the discussion is about whether it is better to run it as normal user or not.
(In reply to comment #10) > I know that you run it as root, but the discussion is about whether it is > better to run it as normal user or not. The summary of this bug is "debuginfo-install suggestion is incorrect" - nothing about how to run yum. Should we rename it? To what? Anyway. Under which user do you propose to run yum, and why this would work better than running it under root?
The original bug mentioned is that on a system freshly installed (I just hit this same bug) that has been updated....if you switch desktop effects to compiz...then off again...compiz crashes. Abrt refuses to submit a backtrace because it needs debuginfo's installed to get a proper trace. It says to run "debuginfo-install compiz" which installs some debuginfo packages but not all. 13 are still missing. This is what the reports lists after performing the debuginfo-install command: Debuginfo absent: 0afdfc236fadadc174323855991e9afa63360400 Debuginfo absent: 145c712e218ab327cdd16ff523056c8ab2c68294 Debuginfo absent: 38bd75b0d94bdf736e935e3f0b6d4ed18bcef7c1 Debuginfo absent: 4c4b1ca2393197e6658f351112ec2ea2f32f9ced Debuginfo absent: 7f2ea4f67236e4eaa45e5f5dd2a0aba85a5309a9 Debuginfo absent: 83afecd9a0aa5d42ea2bb275b48c6385d9cc97b8 Debuginfo absent: 88b05b8bb32e8fc5e1d0c58f165c33a192215685 Debuginfo absent: 8ae7bb8df77cf7fa71cbcd68cf6abca1b1bd37d4 Debuginfo absent: 9b1838e94352154046ccb8e95f396253514a11fb Debuginfo absent: c8bfafb14c6e1c4b21a16765e601d3e7e08f823b Debuginfo absent: dd3d97d610928e4d2686d50c31585b0275faa38d Debuginfo absent: dd5f3280ba24f55fb1e194b962e59647fab8c8b2 Debuginfo absent: e4fb87cca758190ded58a404bc93dd1cd673ac6b Seems there is a broken dependencie somewhere. In fact..i just tried debuginfo-install compiz* cause i figured it was a compiz plugin that was at fault and that got one....probably some easy way to change these checksums back to a package name but i don't know what it is.... The bug is that debuginfo-install compiz does not install everything needed by this backtrace as mentioned originally so the "debuginfo-install suggestion is incorrect" is probably fine.
abrt is not a human. It's just a program. It is seeing that some debuginfos are missing. It suggest what *might* help. It has no brains to figure out that you already did that, but either repositories do not have needed debuginfos, or you need to install differently named package to get them. Or any number of other things. It would take an AI to give you really intelligent suggestions how to make the backtrace better. > i just tried debuginfo-install compiz* cause i figured it was a compiz plugin that was at fault and that got one... Did it help?
If not, this might be the same problem as Bug 547027. The diagnostics in the comments for that bug might be useful in determining whether this is really a gdb failure. --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I think these two bugs are not the same. I can fixing this bug is not so hard. If you run ps aux | grep yum while abrt is trying to determine debuginfo package to be installed, you can see a yum command which shows many packages from many repositories. I think the union of those packages without version number and including --disablerepo='*rawhide*' --disablerepo='*testing*' switches is the solution. I myself run that generated yum command in terminal and find which packages to install.
(In reply to comment #15) > I think these two bugs are not the same. I can fixing this bug is not so hard. > If you run ps aux | grep yum while abrt is trying to determine debuginfo > package to be installed, you can see a yum command which shows many packages > from many repositories. I dont think so. At least more recent versions of abrt do not install packages. abrt first runs: yum --enablerepo=*debuginfo* --quiet provides /usr/lib/debug/.build-id/bb/11528d59940983f495e9cb099cafb0cb206051.debug /usr/lib/debug/.build-id/c5/b84c0ad3676509dc30bfa7d42191574dac5b06.debug ... in order to determine which packages contain needed debuginfos. Then it downloads them (doesn't install, only downloads) using yumdownloader '--enablerepo=*debuginfo*' --quiet $PKG > I think the union of those packages without version > number and including --disablerepo='*rawhide*' --disablerepo='*testing*' > switches is the solution. How/why do you think disabling repos would help? $PKG is unambiguous package name. I just tested, I am getting names like coreutils-debuginfo-7.2-5.fc11.x86_64. Thus yumdownloader should be able to find it with such a generic option like --enablerepo=*debuginfo*. > I myself run that generated yum command in terminal > and find which packages to install. Please be more specific about what you did. I do not understand.
I didn't say that abrt installs packages. I just say that abrt can suggest user to run for example: yum --enablerepo='*debuginfo*' xxx-debuginfo yyy-debuginfo instead of debuginfo-install xxx then user can copy and paste suggested command to a terminal and install them.
As of current F13, abrt-1.0.8-3.fc13 does not allow to report the issue because the backtrace is allegedly unusable, and it urges me to run 'debuginfo-install compiz' beforehand which has already been done successfully pulling in a fair number of debuginfo packqages. Any new attempt to execute 'debuginfo-install compiz' returns "No debuginfo packages available to install".
*** This bug has been marked as a duplicate of bug 575030 ***
I think the problem with this compiz crash is somewhere else, can someone please paste the whole backtrace shown in abrt reporter window? If my feeling is right, then it contains line saying something about "stripped coredump" and that would be the reason why the backtrace is unusable even if the debuginfos are installed. J.