Closed zane131 closed 6 years ago
It turns out that op-build will continue and not exit even if a patch fails:
Applying 2000-FIRDATA-fix-error-handling-for-SCOMs-via-SBE-FIFO.patch using patch:
patching file src/occ_gpe0/firdata/firData.c
patching file src/occ_gpe0/firdata/sbe_fifo.c
Hunk #5 succeeded at 392 with fuzz 2.
Hunk #6 succeeded at 420 with fuzz 2 (offset -7 lines).
Hunk #7 FAILED at 446.
1 out of 7 hunks FAILED -- saving rejects to file src/occ_gpe0/firdata/sbe_fifo.c.rej
patching file src/occ_gpe0/firdata/sbe_fifo.h
https://github.com/open-power/op-build/pull/1359 is the real fix for hostboot, and should likely do the same thing for OCC.
Doing custom code to apply patches doesn't seem to work so well it seems :)
This is a continuation of #1194. The solution for #1194 resolved an issue but did not fix the bug.
I am currently using https://github.com/open-power/op-build/commit/0fcaa6d6d062340667c7beb9377f622bb95e9602. With this, there is an existing patch in the OCC component and I am trying to apply second patch for testing purposes:
Issuing the command to rebuild OCC does not apply the second patch:
Seeing that the first patch is stale and has already been applied, I removed the first patch and rebuilt OCC:
I have seen this happen with Hostboot as well. Basically, if there are any patches that have already been applied, the build tool exits the patching process immediately and moves on with no error. All subsequent patches are ignored.
Yes, I do realize that removing the stale patch 0001-Use-gnu89-as-C-std.patch would resolve this issue, but again it would not fix the bug. The build command should either fail when a patch has already been applied or ensure all other patches are applied as well. One advantage of the former is that we will know immediately if there are any stale patches that need to be removed.