Lo! Quick question on a spec file detail:
On 28.01.2017 16:20, notifications@fedoraproject.org wrote:
From fd6460a8d81a3dc5242b43097a3c96db6737ff3b Mon Sep 17 00:00:00 2001 From: Laura Abbott labbott@redhat.com Date: Sat, 28 Jan 2017 16:16:56 +0100 Subject: Temporary workaround for gcc7 and arm64
See http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461597.ht...
0001-Work-around-for-gcc7-and-arm64.patch | 62 +++++++++++++++++++++++++++++++ kernel.spec | 8 +++- 2 files changed, 69 insertions(+), 1 deletion(-) create mode 100644 0001-Work-around-for-gcc7-and-arm64.patch
diff --git a/0001-Work-around-for-gcc7-and-arm64.patch b/0001-Work-around-for-gcc7-and-arm64.patch […] diff --git a/kernel.spec b/kernel.spec index e31e39c..3e212ce 100644 --- a/kernel.spec +++ b/kernel.spec […] +# See http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461597.ht... +Patch853: 0001-Work-around-for-gcc7-and-arm64.patch
With the current spec file mechanics the above patch won't be applied when the srpm for example is rebuild with "--with nopatches". Such a rebuild thus will fail on rawhide currently due to gcc7 :-/ ran into this on x86-32/-64 when building by vanilla packages.
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.
CU, knurd
On Sat, Feb 11, 2017 at 8:58 AM, Thorsten Leemhuis fedora@leemhuis.info 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.
CU, knurd
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. I would be open to reintroducing something to apply patches here.
Thanks, Justin
On 02/13/2017 05:45 AM, Justin Forbes wrote:
On Sat, Feb 11, 2017 at 8:58 AM, Thorsten Leemhuis fedora@leemhuis.info 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.
CU, knurd
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. I would be open to reintroducing something to apply patches here.
We do apply some of the patches like kbuild-AFTER_LINK.patch always. I just didn't think about that when I applied the gcc patch. FWIW, a real fix should be in Linus' master branch now so it should compile cleanly. Sorry about the trouble.
Thanks, Laura
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@leemhuis.info 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@lists.fedoraproject.org
-
Justin Forbes -
Laura Abbott -
Thorsten Leemhuis