Bug 1084555
| Summary: | patch false positive return code??? | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David Brown <david.brown> | ||||||||
| Component: | patch | Assignee: | Tim Waugh <twaugh> | ||||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 20 | CC: | david.brown, twaugh | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2014-04-09 10:33:47 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 1084558 | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 882785 [details]
The perl file to apply the patch to
Ah, found that the context in the first hunk of the patch contains 3 before and 4 after. So that is a bit different... Odd that patch still didn't produce an error with it though... The RHEL bug is #1084558 This is what I get: $ patch -p5 < xcat-2.8-named-bind-port.patch patching file ddns.pm Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file ddns.pm.rej Did you attach the right version of ddns.pm? Created attachment 883634 [details]
Updated perl without the original patch applied
Sorry, thought this was the one that wasn't applied, looks like I did that on a different system.
I think since the context of the patch is really 3 lines before and 4 lines after patch is interpreting the rest of the patch as garbage? or comments? I thought those were only allowed in the beginning of a patch? Here's what "lsdiff -nvv" (from patchutils) says about it: 3 File #1 a/xCAT-server/lib/xcat/plugins/ddns.pm 5 Hunk #1 So yes, that's the problem: there is an extra context line at the end of the first hunk which causes the rest to be taken as garbage. Here's why. The first hunk's header says "@@ -411,6 +411,16 @@" -- so there should be 6 lines of context in total. That count is wrong. "recountdiff xcat-2.8-named-bind-port.patch" produces a correct patch (it changes the 6 to 7). |
Created attachment 882784 [details] the patch to apply Description of problem: Okay here's some information as to what I've gathered so far... Please disregard the content of the code I'm greping for key words only to call out the behavior I'm seeing. So I think patch is reporting a false positive when trying to apply the patch and I'm unsure of expected behavior. $ grep '^+.*named_listen_rules' xcat-2.8-named-bind-port.patch | wc -l 7 $ grep named_listen_rules ddns.pm | wc -l 0 So after some inspection of the patch and the code you should expect if the patch applies to see 7 new lines with 'named_listen_rules' in the ddns.pm file. $ patch -p5 < xcat-2.8-named-bind-port.patch patching file ddns.pm Hunk #1 succeeded at 482 (offset 71 lines). $ echo $? 0 All seems fine to me nothing in the output or the return code seems to indicate an error, just simply a warning about an offset in one of the hunks. However after another grep. $ grep named_listen_rules ddns.pm | wc -l 5 Seems patch only applied the first hunk and didn't apply the second hunk of the patch file. Is this really expected behaviour?!?!?! Version-Release number of selected component (if applicable): patch-2.7.1-7.fc20.x86_64 patch-2.6-6.el6.x86_64 How reproducible: Very Actual results: The first hunk of the patch was applied with the second seems to be ignored entirely Expected results: I expected both hunks of the patch to be applied. Additional info: I'm concerned this is a 'feature' in patch, so my actual concern is the way rpmbuild is calling patch to make sure there aren't some hidden unpatched hunks that are silently being forgotten in all the patches both Fedora and Redhat has.