Bug 1085486

Summary: %autosetup "-v" option does not affect more patches than the first
Product: [Fedora] Fedora Reporter: Michal Schmidt <mschmidt>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 20CC: jzeleny, novyjindrich, packaging-team-maint, pknirsch, pmatilai
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-10 10:50:21 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:
Attachments:
Description Flags
macros: expand options in %autopatch only once none

Description Michal Schmidt 2014-04-08 17:28:12 UTC
Created attachment 884173 [details]
macros: expand options in %autopatch only once

Description of problem:
When applying more than one patch with "%autosetup -v", the "-v" option affects only the tarball extraction and the application of the 1st patch. The 2nd and subsequent patches are applied quietly.

Version-Release number of selected component (if applicable):
rpm-4.11.2-2.fc20.x86_64

How reproducible:
always

Steps to Reproduce:
1. Have a test.spec with 3 patch files, to be applied using:
   %autosetup -p1 -v
2. rpmbuild -bp test.spec
3. 

Actual results (example of terminal output):
...
+ cd sockperf-2.5.241
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ /usr/bin/cat /home/michich/rpmbuild/SOURCES/0001-Don-t-throw-away-Fedora-s-CXXFLAGS.patch
+ /usr/bin/patch -p1
patching file configure.ac
+ /usr/bin/cat /home/michich/rpmbuild/SOURCES/0002-drop-the-sockperf_-version-copy-of-the-binary.patch
+ /usr/bin/patch -p1 -s
+ /usr/bin/cat /home/michich/rpmbuild/SOURCES/0003-doc-installation-fixes.patch
+ /usr/bin/patch -p1 -s
+ exit 0

Notice that the "-s" option is being added to the second and third /usr/bin/patch invocation.

Expected results:
No invocation of /usr/bin/patch should have the "-s" option.

Additional info:
Interestingly, the "-p" option is not affected.
By experimenting I came up with a patch for /usr/lib/rpm/macros that fixes the bug here, but I do not understand WHY exactly it works. Attached.

Comment 1 Panu Matilainen 2014-04-10 10:50:21 UTC
Fun...

I think I've actually seen this out of the corner of my eye at some point but must've shrugged it off as "too early in the morning, must be seeing things" or something. It has to do with macro scoping, in particular nested parametrized macro invocations which is walking on thin ice already, combined with macro manipulation from %{lua:...} which violates every alleged macro scoping rule there is, due to implementation details. You dont want to know, really :)

Your patch seems like an entirely reasonable workaround for the underlying defiencies, applied and thanks for the patch!