https://koschei.fedoraproject.org/package/cobbler?collection=f33
Fails building the SRPM:
DEBUG util.py:600: error: /chroot_tmpdir/srpm_unpacked/SPECS/cobbler.spec: line 119: %S: argument expected
Line is:
DATE=$(date "+%Y%m%d-%H%M%S")
Do we really have a new rpm macro called %S? From where? (There is a new version of rpm, and new other rpm-macros packages). I'm assuming I would work around this with:
DATE=$(date "+%Y%m%d-%H%M%%S")
?
Thanks.
On 05. 05. 20 1:14, Orion Poplawski wrote:
https://koschei.fedoraproject.org/package/cobbler?collection=f33
Fails building the SRPM:
DEBUG util.py:600: error: /chroot_tmpdir/srpm_unpacked/SPECS/cobbler.spec: line 119: %S: argument expected
Line is:
DATE=$(date "+%Y%m%d-%H%M%S")
Do we really have a new rpm macro called %S? From where? (There is a new version of rpm, and new other rpm-macros packages).
We do. From rpm:
%{S:...} expand ... to <source> file name %{P:...} expand ... to <patch> file name %{F:...} expand ... to <file> file name
https://rpm.org/user_doc/macros.html
I'm assuming I would work around this with:
DATE=$(date "+%Y%m%d-%H%M%%S")
?
Sorry for not asking but I have done this yesterday:
https://src.fedoraproject.org/rpms/cobbler/c/868c803385380d635335ba8e7d6946f...
On 5/5/20 2:44 AM, Miro Hrončok wrote:
On 05. 05. 20 1:14, Orion Poplawski wrote:
https://koschei.fedoraproject.org/package/cobbler?collection=f33
Fails building the SRPM:
DEBUG util.py:600: error: /chroot_tmpdir/srpm_unpacked/SPECS/cobbler.spec: line 119: %S: argument expected
Line is:
DATE=$(date "+%Y%m%d-%H%M%S")
Do we really have a new rpm macro called %S? From where? (There is a new version of rpm, and new other rpm-macros packages).
We do. From rpm:
%{S:...} expand ... to <source> file name %{P:...} expand ... to <patch> file name %{F:...} expand ... to <file> file name
Yup. Note that these built-in primitives are *ancient* (from 3.x days), it's the check for a mandatory argument that is new in 4.16. Up to now it has just silently fallen through.
Hmm, OTOH this is a bit questionable: macro primitives can only take arguments in the %{foo:bar} form, so perhaps the non-%{} form actually should fall through silently.
- Panu -
On 05. 05. 20 8:43, Panu Matilainen wrote:
Hmm, OTOH this is a bit questionable: macro primitives can only take arguments in the %{foo:bar} form, so perhaps the non-%{} form actually should fall through silently.
OTOH I'd argue anything that resembles a macro, even if nonexistent, should fail immediately if not used properly. That means people will be forced to stop accidentally using %stuff in their specfiles waiting for the moment somebody creates a macro of that name.
If we want to avoid mass breakage, maybe at least issue a waening.
I'd consider this useful:
warning: unescaped % in line 666: %HH, macro %HH doesn't exists
As a side note, I don't consider this useful:
warning: extra tokens at the end of %endif directive in line 1073: %endif # with tests
Oops, almost forgot to reply to this...
On 5/5/20 1:36 PM, Miro Hrončok wrote:
On 05. 05. 20 8:43, Panu Matilainen wrote:
Hmm, OTOH this is a bit questionable: macro primitives can only take arguments in the %{foo:bar} form, so perhaps the non-%{} form actually should fall through silently.
OTOH I'd argue anything that resembles a macro, even if nonexistent, should fail immediately if not used properly. That means people will be forced to stop accidentally using %stuff in their specfiles waiting for the moment somebody creates a macro of that name.
That's a fair point, certainly.
If we want to avoid mass breakage, maybe at least issue a waening.
I'd consider this useful:
warning: unescaped % in line 666: %HH, macro %HH doesn't exists
Very much agreed, I actually looked into this just recently. Some discussion and examples of what gets uncovered: https://github.com/rpm-software-management/rpm/pull/1170
The above PR was limited to only %{foo} form of macros, the %foo form is trickier as the spec spec sections appear macros even though they are not, so covering those needs deeper changes into the whole parsing mechanism.
Anyway, this *will* happen sooner or later, undefined macros are such a common source of (packaging) bugs that there's no excuse for rpm to not warn on them. Just like gcc warns on uninitiazed variables.
As a side note, I don't consider this useful:
warning: extra tokens at the end of %endif directive in line 1073: %endif # with tests
Let's just say you're not alone in that. Sadly we're no closer to having a good or even acceptable solution for that.
- Panu -
On 5/4/20 5:44 PM, Miro Hrončok wrote:
On 05. 05. 20 1:14, Orion Poplawski wrote:
https://koschei.fedoraproject.org/package/cobbler?collection=f33
Fails building the SRPM:
DEBUG util.py:600: error: /chroot_tmpdir/srpm_unpacked/SPECS/cobbler.spec: line 119: %S: argument expected
Line is:
DATE=$(date "+%Y%m%d-%H%M%S")
Do we really have a new rpm macro called %S? From where? (There is a new version of rpm, and new other rpm-macros packages).
We do. From rpm:
%{S:...} expand ... to <source> file name %{P:...} expand ... to <patch> file name %{F:...} expand ... to <file> file name
https://rpm.org/user_doc/macros.html
I'm assuming I would work around this with:
DATE=$(date "+%Y%m%d-%H%M%%S")
?
Sorry for not asking but I have done this yesterday:
https://src.fedoraproject.org/rpms/cobbler/c/868c803385380d635335ba8e7d6946f...
Thanks!