Description of problem: Using %{systemd_post} macro in a spec file for rpmbuild causes error: This macro requires some arguments. The error is also very vague since it doesn't tell which macro. Version-Release number of selected component (if applicable): systemd-rpm-macros-245.6-2.fc32.noarch How reproducible: Always Steps to Reproduce: 1. Create simple spec file test.spec that contains %systemd_post as below 2. touch ~/rpmbuild/SOURCES/empty 3. rpmbuild -bs test.spec Actual results: error: This macro requires some arguments Expected results: builds a src.rpm file Additional info: This works in Fedora 30 but not in Fedora 32. Here is the full test.spec: Name: test Version: 1 Release: 1%{?dist} Summary: Test License: GPLv3 Source0: empty %description Test %post %{systemd_post} test.service
Hi Jan, would you know how to implement this? I tried playing with passing an argument to %__systemd_someargs_0, but it doesn't get expanded...
>I tried playing with passing an argument to %__systemd_someargs_0 Why would you? That macro is not supposed to take anything because its result does not depend on arguments passed to systemd_someargs_0. --- %systemd_post() \ %{expand:%%{?__systemd_someargs_%#}} \ if [ $1 -eq 1 ] && [ -x @bindir@/systemctl ] ; then \ # Initial installation \ @bindir@/systemctl --no-reload preset %{?*} || : \ fi \ %{nil} What this does is * %%{?__systemd_someargs_%#} becomes a literal %{?__systemd_someargs_0} or %{?__systemd_someargs_n} for some n that depends on the number of arguments passed to *systemd_post*. * That literal needs to be expanded, hence %expand. * %__systemd_someargs_n is undefined, so will itself expand to nothing due to %{?..} * %__systemd_someargs_0 is defined, so expands to an error. * The remaining sh code as usual If there is a problem with systemd_post in someone's specfile, I cannot reproduce it at present under rpm-4.15.1.
OP made the error of placing the arguments in the wrong place: > %{systemd_post} test.service instead of > %{systemd_post test.service} And the question is whether we could change the definition of %systemd_post so that the error is more informative, for example: > error: %systemd_post macro requires some arguments
just do it like so %__systemd_someargs_0() %{error:The systemd_post macro requires some arguments} If you want %% in the message, it will probably require %%%% because of the expand in systemd_post. But leaving out should be equally clear.
Yep. But %__systemd_someargs is used in 11 places, i.e. we would need 11 different versions of %__systemd_someargs with different messages... That's why I asked if it would be possible to tweak %__systemd_someargs to take an argument that could be used as part of the error message.
============== %__systemd_someargs_0(:) %{error:The %1 requires some arguments} %__systemd_twoargs_2() %{nil} %systemd_post() \ %{expand:%%{?__systemd_someargs_%#:%%__systemd_someargs_%# systemd_post}} \ if [ $1 -eq 1 ] && [ -x @bindir@/systemctl ] ; then \ # Initial installation \ @bindir@/systemctl --no-reload preset %{?*} || : \ fi \ %{nil} %systemd_pre() \ %{expand:%%{?__systemd_someargs_%#:%%__systemd_someargs_%# systemd_pre}} \ if [ $1 -eq 1 ] && [ -x @bindir@/systemctl ] ; then \ # Initial installation \ @bindir@/systemctl --no-reload preset %{?*} || : \ fi \ %{nil} ================
https://github.com/systemd/systemd/pull/16462
Built in rawhide.
FEDORA-2020-2faf839786 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2faf839786
FEDORA-2020-2faf839786 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2faf839786` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2faf839786 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-2faf839786 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.