Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Created attachment 882786[details]
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.
Created attachment 883637[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.
Created attachment 882786 [details] 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.