Description of problem: rm -rf /usr/lib/debug/.build-id GDB stops working. Version-Release number of selected component (if applicable): gdb-7.5.1-38.fc18.x86_64 How reproducible: On one system. Steps to Reproduce: gdb keyctl gdb cal Actual results: Reading symbols from /usr/bin/keyctl...Missing separate debuginfo for /usr/bin/keyctl warning: the debug information found in "/usr/lib/debug//usr/bin/cal.debug" does not match "/usr/bin/cal" (CRC mismatch). Expected results: Reading symbols from /usr/bin/keyctl...Reading symbols from /usr/lib/debug/bin/keyctl.debug...done. Reading symbols from /usr/bin/cal...Reading symbols from /usr/lib/debug/usr/bin/cal.debug...done. Additional info:
The keyctl problem is due to toplevel symlinks in 'filesystem': Bug 974130 The cal problem is due to dwz: Changing .debug file CRC not updating it in the main file referencing it.
Jakub, do you suggest how to fix it? I/whoever could write small tool to update CRC in the binary files according to new recomputed CRC from the referenced dwz-ed .debug file.
Maybe, yeah. dwz doesn't know about the original file, so isn't able to adjust the crc in it.
Created attachment 764751 [details] /usr/lib/rpm/sepdebugcrcfix and its integration. /usr/lib/rpm/sepdebugcrcfix and its integration with /usr/lib/rpm/find-debuginfo.sh . As special package representatives I have tested glibc and kernel and both do not use dwz so sepdebugcrcfix is run there but it does not change the files. kernel build: /usr/lib/rpm/sepdebugcrcfix: Updated 0 CRC32, matched 1564 CRC32. /usr/lib/rpm/sepdebugcrcfix: Updated 0 CRC32, matched 1486 CRC32. /usr/lib/rpm/sepdebugcrcfix: Updated 0 CRC32, matched 1412 CRC32. /usr/lib/rpm/sepdebugcrcfix: Updated 0 CRC32, matched 591 CRC32. It modifies mtime (if the file is updated). dwz also modifies mtime so it is probably OK.
Created attachment 764787 [details] /usr/lib/rpm/sepdebugcrcfix and its integration #2.
Created attachment 764790 [details] /usr/lib/rpm/sepdebugcrcfix and its integration #3.
Ugh. I dont question the need for this, but the debuginfo department is starting to get a bit ... thick. Anyway, added to rawhide now (rpm-4.11.1-2.fc20), lets give it a few days to see if anything breaks before pulling elsewhere. RHEL-7 will obviously need (and benefit from) this as there's a mass-rebuild pending, but what about F19 and F18? Those would only see a limited benefit (through updates) at this point.
wrt the F-18 and F-19 backport: As all the tools I am aware of already use /usr/lib/debug/.build-id/ this problem should not affect normal users. OTOH for tools hackers like me I currently use this tool by hand when doing some hand rpm rebuilds needing to load uninstalled .debug file. Also most used packages also get some updates which would benefit from such a rpmbuild fix backported in F-18/F-19. Up to you.
Ok. Given the rather limited to scope of affected users and distro life cycle, I'll pull it into F19 but leave F18 alone.
rpm-4.11.1-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/rpm-4.11.1-1.fc19
Package rpm-4.11.1-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing rpm-4.11.1-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-12411/rpm-4.11.1-1.fc19 then log in and leave karma (feedback).
rpm-4.11.1-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.