On 05/23/2017 04:23 AM, Mark Wielaard wrote:
> 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).
>
Yes, I would like to get unique names going sometime as well.
>>> 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.
>
I'd prefer to just keep it off unless we want actual Minisymtab support
for the kernel.
> Thanks,
>
> Mark
I dropped the patch into rawhide so it should start showing up
in builds in the next few days.
Thanks for all the review and feeback!
Laura
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
