Bug 1083407 - Patch does not recognize bad patch, says the patching succeeded, but file is not patched
Summary: Patch does not recognize bad patch, says the patching succeeded, but file is ...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: patch
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-02 08:01 UTC by Jan Kaluža
Modified: 2015-03-09 17:30 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-03-09 17:30:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
reproducer (1.12 KB, patch)
2014-04-02 08:01 UTC, Jan Kaluža
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
GNU Savannah 44494 0 None None None Never

Description Jan Kaluža 2014-04-02 08:01:29 UTC
Created attachment 881659 [details]
reproducer

If the patch does not contain following header:
--- a/src/file.h
+++ b/src/file.h

patching looks like this, but the file is not patched:

$ patch -p1 < file-5.11-maxmime.patch ; echo $?
patching file src/file.h
0

This can cause problems during rpmbuild when the broken patch looks like the proper one, but files are not patched in the end.

Comment 1 Jaroslav Reznik 2015-03-03 15:39:23 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 2 Tim Waugh 2015-03-09 17:30:10 UTC
In general, hand-edited patches will always cause issues like this because damage cannot always be detected.

In this particular case, I agree it's unexpected.


Note You need to log in before you can comment on or make changes to this bug.