Description of problem: Version-Release number of selected component (if applicable): How reproducible: I am a bugmaster of the all gecko files. We have bugs where reporter when asked for stacktrace, even when using debuginfo-install produces back with missing debuginfo information. See bug 431162 comment 13 for an example. Steps to Reproduce: 1. ask reporter for backtrace from firefox and explain them how to get debuginfo information 2.wait for their response 3. Actual results: plenty of missing debuginfo information Expected results: useful backtrace (even when poor reporter has to install tons of -debuginfo packages)
need more info. What packages is it that debuginfo-install didn't get? Is there a heuristic to them?
Take a look at the attachment 294191 [details] (linked to the comment I referred to) -- /usr/lib/xulrunner-1.9pre/libxul.so debuginfo information is missing.
IMO this problem is a DUPLICATE of either: Bug 151598: Debug info RPMs do not "require" exact maching binary rpm - so that the users do not have the matching debuginfo version installed. (patch provided with no feedback) and/or Bug 235755: rpm doesn't allow 'Requires: foo.%{ARCH}' - so that the x86_64 requirements get falsely satisfied by the i386 packages. (fixed upstream but Rawhide still does not have the backport) (Bug 427579 is also ugly for any user acceptable debuginfos handling) To make the problem solvable/reproducible it would be best to get from the target system first: rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n' to be aware what in fact is the problem there.
Setting NEEDINFO on myself, and waiting for satysfying other NEEDINFO in bug 431162 comment 19
Matej I thought I'd comment on this here, small issue with getting the firefox and xulrunner debuginfo sync'd up right now on i686. This does not happen on x86_64 when doing main arch only. Updating: firefox i386 3.0-0.beta3.21.nightly20080214.fc9 development 1.4 M firefox-debuginfo i386 3.0-0.beta3.21.nightly20080214.fc9 development-debuginfo 625 k xulrunner i386 1.9-0.beta3.22.nightly20080215.fc9 development 9.5 M xulrunner-debuginfo i386 1.9-0.beta3.22.nightly20080215.fc9 development-debuginfo 64 M Transaction Check Error: file /usr/src/debug/mozilla/memory/jemalloc/jemalloc.c conflicts between attempted installs of firefox-debuginfo-3.0-0.beta3.21.nightly20080214.fc9.i386 and xulrunner-debuginfo-1.9-0.beta3.22.nightly20080215.fc9.i386 I attached a new backtrace with matched x86_64 debuginfo to bug# 431162
Jan, the requested information is attachment 295021 [details]
Sorry, I meant the attachment 295039 [details] (on i386) and the attachment 295040 [details] (on x86_64).
The debuginfo problem part in Bug 431162 was due to debuginfo rpms out of sync. The user did `debuginfo-install APPNAME' but later `yum update' commands did no longer update the associated debuginfos. rpm currently permits installing PKG-2.rpm together with PKG-debuginfo-2.rpm. I was attempting to disallow such state in Bug 151598 but it is no longer wanted behavior: In future (F10) we should have the possibility of simultaneously installed: PKG-debuginfo-1.rpm PKG-debuginfo-2.rpm (draft patches at http://people.redhat.com/jkratoch/multidebug/ ). => I would like yum (not yum-utils) to automatically: If it is UPDATING PKG from version 1 to 2 it should: - Check if PKG-debuginfo-1 is installed and if it is then: * enable the -debuginfo repos for enabled primary repos * UPDATE PKG-debuginfo from version 1 to explicitely version 2 - Do not update to version 3 even if it would be available. - PKG-debuginfo-2 should exist, not sure what to do if it does not. - Do not care of the other versions of PKG-debuginfo installed. (probably) if it is REMOVING PKG of version 1, remove also PKG-debuginfo-1 - Do not care of the other versions of PKG-debuginfo installed. I am not so Python friendly, do you have a requirement for a patch? Thanks.
(In reply to comment #5) > Transaction Check Error: > file /usr/src/debug/mozilla/memory/jemalloc/jemalloc.c conflicts between > attempted installs of firefox-debuginfo-3.0-0.beta3.21.nightly20080214.fc9.i386 > and xulrunner-debuginfo-1.9-0.beta3.22.nightly20080215.fc9.i386 This packaging problem was cloned into Bug 433200.
in response to comment #8. I don't see it happening. Enabling repos based upon what we see is installed is doing more thinking for the user than I think they want. If the user doesn't specify the repos they want, then they don't get those repos. That's really all there is to it. I'm sorry.
Seth, you have certainly point — we don’t want to make Microsoft Bob. Right. On the other hand, I would really need 100% foolproof method how to get all my reporters to get fully working debuginfo information. So, couldn’t we have something like --debuginfo parameter to yum install? Wait, we have it, that’s what debuginfo-install is all about! However, that doesn’t work well — that’s what this bug is about! I don’t understand well, what’s the problem, but I am quite sure, that when reporter runs debuginfo-install, she *wants* all debuginfo to be installed, whether that means enabling debuginfo repositories or not. So, why it doesn’t work?
Or should I just warn reporters that after using debuginfo-install they should immediately run gdb and provide the information I asked them to provide, before the next yum upgrade will screw their *-debuginfo pacakages? Jan, will getting backtraces immediately after running debuginfo-install provide foolproof method of getting all debuginfo resolved?
Yes, if the packaging is done properly then yum will warn the users that the debuginfo rpms will be removed if they do the upgrade (if this isn't happening it's a bug somewhere). At which point the user will make the choice for what do to (including enabling the debuginfo repos, and everything doing the right thing) -- yum-aliases already has the ad. hoc. DBG/SRC aliases to do this for Fedora GA/updates repos. We could do a real plugin for the same --dbgrepos and --srcrepos? But I'm not sure we'd want this in the default yum command, and Seth probably has an even stronger opinion on that. It's also possible for us to have something like: debuginfo-install --enablerepos blah ...where it would install the debuginfo rpms for blah (and it's deps) but also enable the debuginfo repos. Getting them turned off again doesn't have an obvious UI though, and given that this would push pain onto the users I'm not sure it's the correct approach.
Ok, so I was confused ... if the deps. are correct yum won't remove things automatically ... it just won't update the affected pkgs (unless the user manually remove the -debuginfo variants). But that's roughly the same end result ... working deps + debuginfo-install == debug info is there for gdb.
(In reply to comment #11) > So, why it doesn’t work? Here is what's happening. A user encounters a problem and is told to debuginfo-install the packages for the software in question. debuginfo-install installs debuginfo packages for the package(s) specified and all of their immediate dependencies. Afaik this works correctly and as designed. The trouble is that the user then performs an update and the debuginfo files no longer match up. So the user needs to run debuginfo-install that package name, again, so they get the most recent debuginfo packages that match with the binary packages they are actively running. Now, your question is - why, after running debuginfo-install, are debuginfo repositories not defaulting to on. The reason is simple, the user doesn't want them on all the time. They only want them on when they are needed. A user does not want to download metadata updates for the debuginfo repositories b/c excluding the exceptional debug cases they never use them and they just waste bandwidth and diskspace. Does that explain why we don't turn them on automatically? if a user wants to update all of their debuginfo packages in one command, run this: yum --enablerepo='*-debuginfo' update This still isn't a bug here afaict.
So, is my comment 12 good enough answer for my purposes?
(In reply to comment #13) > Yes, if the packaging is done properly then yum will warn the users that the > debuginfo rpms will be removed if they do the upgrade (if this isn't happening > it's a bug somewhere). No, because having PKG-1.rpm with PKG-debuginfo-2.rpm is a valid state if one is analysing a core file from remote system where PKG-2.rpm is installed. Or debugging PKG-2 remotely or running systemtap for remote kernel etc. I wrote these reasons in the Comment 8. So there cannot be the rpm hard Requires/Conflicts restrictions. Still there should be some soft "Recommends" (present in .deb, not in .rpm) so that in the most common UPDATE case the debuginfos already matching the installed versions get updated along. (In reply to comment #14) > Ok, so I was confused ... if the deps. are correct yum won't remove things > automatically ... it just won't update the affected pkgs (unless the user > manually remove the -debuginfo variants). Please see above. (In reply to comment #15) > Now, your question is - why, after running debuginfo-install, are debuginfo > repositories not defaulting to on. The reason is simple, the user doesn't want > them on all the time. This is not about "all the time". Most of the people will never have any debuginfo packages installed and therefore debuginfo repositories do not get enabled. The moment YUM updates PKG-1 to PKG-2 and does NOT update the installed PKG-debuginfo-1 to PKG-debuginfo-2 a problem happened. The solution possibilities are: (1) Refuse debuginfo-install if the debuginfo repositories are not enabled. (2) Enable the debuginfo repositories ONLY IF we find the problem is going to happen - if we found we are updating PKG-1 but PKG-debuginfo-1 is installed. This was suggested in the Comment 8. (?) More? > They only want them on when they are needed. Yes, I agree, therefore I was proposing the point (2) or Comment 8 above. > A user does not want to download metadata updates for the debuginfo > repositories b/c excluding the exceptional debug cases they never use them > and they just waste bandwidth and diskspace. Right, in such case the debuginfo repositories would never get enabled according to the point (2) or Comment 8 above. > if a user wants to update all of their debuginfo packages in one command, People want to update their system - they forgot they installed some debuginfo packages before. > run this: > > yum --enablerepo='*-debuginfo' update But the real world users do not do it - please see the Bug 431162 for an example.
What if debuginfo-install grew an 'update' option? Then you could ask users to make sure all of their debuginfo files are updated when it is necessary.
(In reply to comment #18) > What if debuginfo-install grew an 'update' option? > > Then you could ask users to make sure all of their debuginfo files are updated It must be automatic. System with debuginfos out of sync is broken. > when it is necessary. It is always necessary when the debuginfos are installed. Otherwise they must get uninstalled.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
debuginfo files should be considered temporary. If you really need them to be kept up-to-date, enable the debuginfo repo(s). By default, we should delete out-of-date debuginfo files periodically. Or delete them after yum upgrades.
Yes, the Comment 21 looks fine even for me.
Just a heads up for the rpm5.org implementation in Bug 447708 Comment 7. I have not tried it, though.
We can add a yum-util (or an option to debuginfo-install) to clean out old debuginfo pkgs. Any preferences?
debuginfo-install --cleanup, would probably be my first guess
I did a testcase run for the Joe user: 1:I have coreutils-6.12-17.fc10.x86_64 installed. 2:I run: gdb /bin/echo 3:I am told and so run: Missing separate debuginfos, use: debuginfo-install coreutils-6.12-17.fc10.x86_64 4:GDB works now. 5:I do (with default *.repo using -debuginfo repos disabled): yum -y update 6:Now I get installed: coreutils-6.12-18.fc10.x86_64 coreutils-debuginfo-6.12-17.fc10.x86_64.rpm 7:I run: gdb /bin/echo 8:I am told and so run: Missing separate debuginfos, use: debuginfo-install coreutils-6.12-18.fc10.x86_64 Please note debuginfo-install does correctly an update here instead of a new installation that would cause two simultaneous debuginfo pkgs conflicts. 9:GDB works now. In fact there is nothing too much serious, if one follows the advices it works. Just in point 6 we have a useless debuginfo package installed. So the point 5 should either (a) Remove the no longer valid debuginfo packages or (b) Update the debuginfo packages out of sync. Not asking for any explicit option as the Joe user will never use such one.
I sounds like from comment 26 that we should close this notabug agreed?
Not agreed. It is a real yum or rpm bug although I agree a lower priority one (and it is now already `low').
I guess I'm confused, then. What's the requested course of action?
Already requested in Comment 8 and Comment 17 (2): If it is UPDATING PKG from version 1 to 2 it should: - Check if PKG-debuginfo-1 is installed and if it is then: * enable the -debuginfo repos for enabled primary repos * update PKG-debuginfo from version 1 to explicitely version 2
This is not a bug. The problem you're having is this: You want debuginfo packages to be updated along with the rest of the system. As mentioned in comment #21, this is a solved problem: just enable the debuginfo repos. The behavior you're asking for is exactly the same, except you want it to work *without* enabling the repos. That's just silly. Enable the repos if you want debuginfo kept up to date! A more useful solution would be to write a yum plugin that *removes* out-of-date debuginfo packages when their parent packages are removed. So make this an RFE for that yum plugin, or close NOTABUG.
(In reply to comment #31) > The problem you're having is this: You want debuginfo packages to be updated > along with the rest of the system. As mentioned in comment #21, this is a > solved problem: just enable the debuginfo repos. The problem is that debuginfo-install will install the new -debuginfo packages WITHOUT having to enable the debuginfo repos. If the requirement for a working system with any -debuginfo installed is to enable debuginfo repos then: debuginfo-install should refuse to run until the user enables the debuginfo repos. > A more useful solution would be to write a yum plugin that *removes* > out-of-date debuginfo packages when their parent packages are removed. From the user POV: (1) I have a longterm crashing problem with pidgin: debuginfo-install pidgin (2) Debugging it with upstream, sending sometimes bugreports them, it still sometimes crashes. (Based on my own experience.) (3) As the time goes sometimes I / PackageKit do `yum update'. (4) Now I found the debuginfos for pidgin are either out-of-sync or missing. Why? I have never run any debuginfo-remove command. debuginfo package is a first class citizen, nothing which can be quietly removed.
Ok, yum-plugin-auto-update-debuginfo added upstream: http://yum.baseurl.org/gitweb?p=yum-utils.git;a=commitdiff;h=ce873c479506dd4847e6c1c90c08516b2315d848
Works fine, thanks!
*** Bug 483914 has been marked as a duplicate of this bug. ***
It seems like the problem persists in rawhide. Look at bug 548311 and bug 550516. Not sure if it is a bug of yum for now...