Example: /usr/bin/debugedit: /var/tmp/portage/dev-lang/python-2.7.18-r6/image/usr/lib64/python2.7/lib-dynload/_struct.so: Unknown debugging section .debug_loclists /usr/bin/debugedit: /var/tmp/portage/dev-lang/python-2.7.18-r6/image/usr/lib64/python2.7/lib-dynload/_struct.so: Unknown debugging section .debug_rnglists /usr/bin/debugedit: /var/tmp/portage/dev-lang/python-2.7.18-r6/image/usr/lib64/python2.7/lib-dynload/_struct.so: DWARF version 5 unhandled /usr/bin/debugedit: /var/tmp/portage/dev-lang/python-2.7.18-r6/image/usr/bin/python2.7: Unknown debugging section .debug_loclists /usr/bin/debugedit: /var/tmp/portage/dev-lang/python-2.7.18-r6/image/usr/bin/python2.7: Unknown debugging section .debug_rnglists /usr/bin/debugedit: /var/tmp/portage/dev-lang/python-2.7.18-r6/image/usr/bin/python2.7: DWARF version 5 unhandled Reproducible: Always
There is this: https://github.com/rpm-software-management/rpm/pull/1332
I guess we'll have to wait for upstream to merge this. I can do a backport then if necessary, though I suppose it'd be better to wait for a release.
*** Bug 792441 has been marked as a duplicate of this bug. ***
Created attachment 714051 [details] debugedit-0.2.ebuild Trivial ebuild for nascent split debugedit project background: Getting recent rpm to build (with or without debugedit) seemed infuriatingly difficult and confusing. I'm sure I was just doing something dumb and it's not so bad, but I tried to figure it out for hours without success. Scouring the 'net for hints I stumbled across these: http://lists.rpm.org/pipermail/rpm-ecosystem/2021-February/thread.html#734 https://sourceware.org/bugzilla/show_bug.cgi?id=27351 So the whole stupid problem is actually in the process of being properly solved and we can trivially leverage this. Attached is a no-phase-function ebuild for this project. Not sure about the popt dep, is that about appeasing rpm or a real thing? Anyhow, bazinga! Enjoy your debug symbols again ... or, quite plausibly, enjoy debugging why they don't actually work despite this ebuild :)
Looks like standalone debugedit 5.0 has been tagged as of a few days ago: https://sourceware.org/git/?p=debugedit.git;a=commit;h=1745c1e80772a6c2cb53db2507ce1f07d49691e3
Created attachment 736210 [details] debugedit-5.0.ebuild Update to 5.0 release
Created attachment 736213 [details, diff] files/debugedit-5.0-readelf-autoconf.patch patch in bugfix from upstream
Created attachment 736216 [details, diff] files/debugedit-5.0-include_dir_entry_zero.patch pull in upstream gcc 11.2.1 compatibility patch
ping, did they ever reply to you upstream mgorny?
(In reply to Sam James from comment #9) > ping, did they ever reply to you upstream mgorny? Reply about what?
Comment on attachment 736210 [details] debugedit-5.0.ebuild Please don't attach files unless you're going to attach signed-off git patches. There's a big warning above the attachment form about that.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=51b2dbe87f72d578e34b628da47826a6a727127b commit 51b2dbe87f72d578e34b628da47826a6a727127b Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2021-09-03 06:43:48 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2021-09-03 06:53:39 +0000 dev-util/debugedit: Bump to 5.0 Closes: https://bugs.gentoo.org/768444 Signed-off-by: Michał Górny <mgorny@gentoo.org> dev-util/debugedit/Manifest | 2 + dev-util/debugedit/debugedit-5.0.ebuild | 42 +++ .../debugedit/files/debugedit-5.0-readelf.patch | 330 +++++++++++++++++++++ .../files/debugedit-5.0-zero-dir-entry.patch | 130 ++++++++ 4 files changed, 504 insertions(+)
(In reply to Michał Górny from comment #10) > (In reply to Sam James from comment #9) > > ping, did they ever reply to you upstream mgorny? > > Reply about what? Ah, I meant the versioning problem, but it's resolved ;)
