On 13.02.2017 19:01, Laura Abbott wrote:
> On 02/13/2017 05:45 AM, Justin Forbes wrote:
>> On Sat, Feb 11, 2017 at 8:58 AM, Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote:
>>> No big deal for me, nevertheless a quick question: Until a year or two
>>> ago that didn't happen: The spec file had a few tricks to apply some of
>>> the patches (for example those that fix know build/compiler problems)
>>> all the time. That was lost when the spec file switched to using "git am
>>> %{patches}" to apply patches.
>>> Was that intentional? Laura, Justin: Would you be open to reintroduce
>>> and use a similar method that would apply certain patches all the time?
>>> If yes I'd might look into this sooner or later, as it would make my
>>> life easier.
> […]
>> No, it was not intentional that I am aware of. just something that no
>> one seemed to notice until now because build issues are fairly rare
>> these days.
Yeah, it iirc was only the second or third time in the past year that I
ran into such a problem.
>> I would be open to reintroducing something to apply
>> patches here.
> We do apply some of the patches like kbuild-AFTER_LINK.patch always.
Yeah, because it's listed as SOURCE (And applied all the time), and not
as a PATCH in the spec file.
> I just didn't think about that when I applied the gcc patch.
So what do you suggest how to handle a situation like this in the
future? Will you simply add compile fixes as SOURCE and add a dedicated
command to apply it all the time? Or should we add some spec file magic
to make sure some patched are applied, but not applied twice? Something
like this maybe (pseudo-code, untested)?
"""
[…]
# put patches to fix build errors here
Patch001: 0001-Work-around-for-gcc7-and-arm64.patch
%if !%{nopatches}
# Git trees.
# Standalone patches
# a tempory patch for QCOM hardware enablement. Will be gone by end of
2016/F-26 GA
Patch420: qcom-QDF2432-tmp-errata.patch
[…more Fedora-specific patches…]
%endif
[…]
%if 0%{?%patches:1}
git am %{patches}
# END OF PATCH APPLICATIONS
%endif
"""
Hmmm. I'm not sure if I like that to much myself. Anyone got a idea how
to make it more obvious/straight-forward what's happening?
> FWIW,
> a real fix should be in Linus' master branch now so it should compile
> cleanly. Sorry about the trouble.
No worries, no big deal.
CU, knurd
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
