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.
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!