Hi,
On Fri, 2017-05-05 at 10:40 -0400, Don Zickus wrote:
On Thu, May 04, 2017 at 04:38:25PM -0700, Laura Abbott wrote:
>
> Once upon a time, the kernel needed a lot of special handling to
> generate proper debuginfo as the kernel was ahead in technology. These
> days, rpm has improved debuginfo support. The kernel has not kept up
> with this and it's forward looking calls are now out of date. Switch to
> more standard invocations of debuginfo calls.
> ---
> v3: Adds the new flag to never touch the buildids. I think I got the
> BuildConflicts tag correct?
Yes, I believe so. Version 4.13.0.1-19 has all the fixes needed.
Thanks for the work! The patch seems reasonable to me. I will let
Mark
comment on it too.
Yes, it looks like a good cleanup. I am glad this gets rid of the
AFTER_LINK patch which assumed that double debugedit invocation is
idempotent. Which it isn't anymore now that we want to generate unique
debug-names and build-ids. We still have to figure out some way to
enable that for the kernel builds though. I think rpm needs to become a
little smarter about finding out which files might embed other images
that might contain build-ids (the vdsos, the compressed kernel modules
and the compressed kernel image itself for which the kernel.spec does
contain workaround currently).
> diff --git a/kernel.spec b/kernel.spec
> index 27c4fe13..06fcf3d4 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -395,7 +395,16 @@ BuildRequires: pciutils-devel gettext ncurses-devel
> BuildConflicts: rhbuildsys(DiskFree) < 500Mb
> %if %{with_debuginfo}
> BuildRequires: rpm-build, elfutils
> -%define debuginfo_args --strict-build-id -r
> +BuildConflicts: rpm < 4.13.0.1-19
> +# Most of these should be enabled after more investigation
> +%undefine _include_minidebuginfo
I think with 4.13.0.1-19 you can drop this undefine. Because it has:
- Minisymtab should only be added for executables or shared libraries.
Or you could first do a version with it undefined and then remove it in
a later patch if you want to double check.
Thanks,
Mark