We should use the official rpm tarball to build debugedit: Source: https://github.com/rpm-software-management/rpm/tree/master/tools Official releases: http://rpm.org/download.html The current ebuild is using dev hosted sources: https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/debugedit/debugedit-5.3.5-r1.ebuild#n15 This makes it hard to up rev the package. The reason I care is that the latest version of debugedit does not have a dependency on beecrypt. I'm not sure where the current version numbers came from either. Latest RPM version is 4.14.1, so not sure where the ebuilds 5.3.5 version came from. I personally think the ebuild should track the RPM version number, but not sure how we go about changing that.
the tarball was built from official sources. iirc, there wasn't a good option for creating/building this other than ripping it out by hand from the tarball. the 5.x series comes from the RPMv5 project. feel free to read about the convoluted history of the two projects. it's a mess. it looks like RPMv5 now though is dead, and Redhat is doing sane releases on GH. so feel free to add a new ebuild that is based off the rpm.org releases.
How would I go about down reving the version number?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4056752249ee4c6d6bd9bfe1244c62641c36ed11 commit 4056752249ee4c6d6bd9bfe1244c62641c36ed11 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2018-05-30 19:42:14 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2018-05-30 19:44:29 +0000 dev-util/debugedit: reversion current stable #653906 We want to switch release streams from the RPMv5 project to the RedHat RPM project on GitHub as the RPMv5 project is dead now. Unfortunately, the RH versions are in the 4.x range, and we're already at 5.x, so we need to move this to something smaller for unstable to upgrade to. Add a "0." prefix for existing users (stable & unstable) to "downgrade" to so the new 4.x series will be an upgrade for everyone. It means a useless rebuild, but this package is tiny, so shouldn't be a big deal. Bug: https://bugs.gentoo.org/653906 .../{debugedit-5.3.5-r1.ebuild => debugedit-0.5.3.5-r1.ebuild} | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
done
Thanks! I'll try and add a new ebuild soon.
I think this debugedit program is providing the following in Gentoo: 1) Sets the build-id Which can instead be replaced with passing --build-id to the linker (if the recent toolchain is not already setting a build-id by default): https://fedoraproject.org/wiki/Releases/FeatureBuildId 2) It does a mapping from where the debug symbols and source code are built to where they are installed. It does a poor job of this, as it does not map the locations of the .dwo files that are generated when debug fission is used by seting: CFLAGS="${CFLAGS} -gsplit-dwarf" LDFLAGS="${LDFLAGS} -Wl,--gdb-index" And anyway, this functionality can be replaced in a way that does fix the mapping of the .dwo files as well by setting (in say /etc/portage/make.conf): CFLAGS='${CFLAGS} -fdebug-prefix-map=\${WORKDIR}=/usr/src/debug/\${CATEGORY}/\${PF}' 3) It prints out the list of source files that should be installed in /usr/src/debug. Although this is also wrong as it is missing the .dwo files. It is easy to append the missing .dwo files with a wrapper: #!/bin/sh shift @GENTOO_PORTAGE_EPREFIX@/usr/bin/debugedit-bin $@ find "${WORKDIR}" -name \*.dwo -print | sed -e "s@^${WORKDIR}/@@g" | tr '\n' '\000' >>$6 We could come up with a find command to look for source code files, although that would install source code files are at not in the executables and libraries that are installed. If you like I think I could write a python and/or bash programs to pass the output of objdump --dwarf to come up with the list of source code files, if you like the idea of replacing debugedit with a python and/or bash script(s). 4) debugedit breaks with dwarf 5. 5) debugedit prints an error: Unknown debugging section .debug_addr Although it does still provide the list of source files with the workarounds that I am using as described above.
Should we file bugs with upstream debugedit so they can fix the dwo and dwarf 5 issues?
Added 4.14.2. Please test and report any issues you have.
