On Sun, Dec 31, 2017 at 9:13 PM, Laura Abbott <labbott@xxxxxxxxxx> wrote:
> On 12/30/2017 04:52 AM, Paul Bolle wrote:
>>
>> 0) The v4.14.10 stable updates adds a new executable (tools/objtool/sync-
>> check.sh). Somehow this was added non-executable during my local build of
>> v4.14.10 (on fc26, that is). This made the build fail:
>>
>> [...]
>> + make -s ARCH=x86_64 V=1 -j4 bzImage
>> make[2]: execvp: ./sync-check.sh: Permission denied
>> make[2]: *** [Makefile:49:
>> [...]/BUILD/kernel-4.14.fc26/linux-4.14.10-1.local0.fc26.x86_64/tools/objtool/objtool]
>> Error 127
>> make[1]: *** [Makefile:62: objtool] Error 2
>> make: *** [Makefile:1623: tools/objtool] Error 2
>> make: *** Waiting for unfinished jobs....
>> error: Bad exit status from /var/tmp/rpm-tmp.fTUkoT (%build)
>>
>>
>> RPM build errors:
>> Bad exit status from /var/tmp/rpm-tmp.fTUkoT (%build)
>>
>> Anybody else seeing this?
>>
>
> Yes, this was something that needed a fixup in rawhide. I added
> the appropriate chmod. 4.14.10 is now building for F27 and F26.
>
>> 1) Switching the specfile from patch to "git apply" seems to do the right
>> thing. This is what I tried:
>>
>> diff --git a/kernel.spec b/kernel.spec
>> index 965345c2a26e..b2a1ffbe843d 100644
>> --- a/kernel.spec
>> +++ b/kernel.spec
>> @@ -1267,8 +1267,9 @@ fi
>> # released_kernel with possible stable updates
>> %if 0%{?stable_base}
>> # This is special because the kernel spec is hell and nothing is
>> consistent
>> -xzcat %{SOURCE5000} | patch -p1 -F1 -s
>> -git commit -a -m "Stable update"
>> +xzcat %{SOURCE5000} | git apply -
>> +git add -A
>> +git commit -m "Stable update"
>> %endif
>> # Drop some necessary files from the source dir into the buildroot
>>
>> 2) Would it make sense to further gitify the specfile and move from patch
>> to
>> "git apply" here (and a few other places)? Or should we expect patch to do
>> the
>> right thing? (In the latter case I guess I might have to report a bug
>> against
>> patch.)
>>
>
> We've generally been expecting patch to do the right thing and it's
> worked so far. I'm not opposed to gitifying more parts of the spec
> file but do you have a particular reason for doing so? It seemed
> like when Josh made the original change for git he had a few things
> in mind.
I have to put on my time-machine cap to even try and remember. Here's
the best I can come up with.
If you look at where the cases where patch is being used, you'll
notice that some of them are before 'git init' is even run. So as it
stands currently, you can't use git apply because the git repo doesn't
actually exist at those points. Why that is boils down to 2 things:
1) Laziness and/or change minimalization when we introduced this. You
might be able to move around the git init so you can use git apply,
but I just didn't bother at the time for reasons I don't remember.
2) Upstream sucks at patch generation. If you look at the stable or
RC patches, they aren't nice mboxes of discreet commits. They're
giant, code-only diffs that don't preserve individual changes at all.
Looking at that you wind up just applying the changes wholesale and
then doing a commit with "baseline" as the commit message. Given that
the commit logs of the git tree during the build itself are useless
anyway (because koji doesn't read the commit logs), it doesn't matter
but it's still disappointing. It means we wind up having to create
the exploded tree with tooling after the fact. Oh well.
So if you want to use git apply instead of patch, I have no objections
that I can remember. It'll just require some extra work to make sure
the git repo actually exists and that doesn't break other things.
josh
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
