Install python-srpm-macros-3.9-37.fc35 on rawhide. The macro file is /usr/lib/rpm/macros.d/macros.python-srpm With rpm-4.16.1.3-1.fc35.x86_64, I get: # rpm --eval %pypi_source https://files.pythonhosted.org/packages/source/%/%name/%name-%version.tar.gz # rpm --eval '%py3_dist foo' python3dist(foo) # rpm --eval '%py_dist_name foo_bar' foo-bar # rpm --eval %python_extras_subpkg error: %python_extras_subpkg: missing option -n (name of the base package) error: lua script failed: [string "<lua>"]:12: error expanding macro With rpm-4.16.90-0.git15395.2.fc35.x86_64, I get: # rpm --eval %pypi_source %pypi_source # rpm --eval '%py3_dist foo' %py3_dist foo # rpm --eval '%py_dist_name foo_bar' %py_dist_name foo_bar # rpm --eval %python_extras_subpkg %python_extras_subpkg This makes at least 1000 Fedora packages fails to build from source (most likely fail to build the SRPM) with errors like: error: Bad source: /builddir/build/SOURCES/%{pypi_source}: No such file or directory
Non-Lua macros from the same file work as before: # rpm --eval %python3 /usr/bin/python3 # rpm --eval %python3_pkgversion 3 Lua macros from different files still work: # rpm --eval '%pycached %{python3_sitelib}/foo.py' # from /usr/lib/rpm/macros.d/macros.python3 /usr/lib/python3.9/site-packages/foo.py /usr/lib/python3.9/site-packages/__pycache__/foo.cpython-39{,.opt-?}.pyc
This blocks our Python 3.10 rebuild. It can also make packages build fine, but suddenly no longer build a subpackage with https://fedoraproject.org/wiki/Changes/PythonExtras -- but only for packages that only use (conditional) %python_extras_subpkg and not %pypi_source or %py3_dist.
Created attachment 1775859 [details] A diff between old and new `rpm --showrc` in an otherwise identical mock I've attached a diff between old and new `rpm --showrc` in an otherwise identical mock.
Yup, easily reproduced. It's a regression introduced in https://github.com/rpm-software-management/rpm/commit/75275a87cff04da65d3557f2c40ea2b526528c4c and what it trips over is this comment line in that macro file: > Set to /bin/true to avoid %ifdefs and %{? in specfiles I'll revert the patch in rawhide to let builds continue and look for the proper fix afterwards. Just a sec.
I've just debugged that macros above `# Set to /bin/true to avoid %ifdefs and %{? in specfiles` work fine and macros below don't. You were faster Should I escape the % in the comment? That sound s safer.
Like this: https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/97
It's a good question. In *spec* comments, macros are always expanded, but I don't recall offhand what should happen in macro file comments. Feel free to escape though, it's probably the best immediate fix. There is a bug in rpm nevertheless (either the %{ should be ignored in a comment or there should be an error for missing }).
Building new rpm with the problematic patch reverted now: https://koji.fedoraproject.org/koji/taskinfo?taskID=66775049
Thanks for the revert. I'll also land https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/97
I wonder if it's better to just use %dnl "comments" in macro files instead of worrying about escaping rules.
%dnl will *not* work in macro files because macro files are not expanded as they're read.
So, as discussed in the upstream ticket, this wasn't so much a regression but unearthing an ancient bug - a bunch of macros in the same file were always being skipped due to the bug, but an otherwise unrelated change which permits macro body to include empty lines dragged the bug into the spotlight. Upstream fix was to not let comments affect parsing. I've reverted the revert, and added the upstream fix instead. Was about to close this but then it already was.
FEDORA-2021-831cfbf901 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.