In favor of #6 I'm creating this new issue. Suppose you have a spec file like this:
%global yyyymmdd %{lua: print(os.date("%Y%m%d"))} Name: foo Version: 13.0.0 Release: 1 Summary: Foo License: Foo Source0: https://github.com/kwk/llvm-project/releases/download/source-snapshot/llvm-release-%{yyyymmdd}.txt #%%if ! 0%{?in_spectool} %global llvm_version %{lua: print(io.lines(rpm.expand("%{SOURCE0}"))())} %{echo: llvm_version=%{llvm_version}} #%%endif %description My Description
And you process it with spectool, you'll get this error:
spectool
$ rm -vf ~/rpmbuild/SOURCES/llvm-release-2021*.txt && spectool -R -g test.spec [...] error: lua script failed: [string "<lua>"]:1: cannot open file '/home/kkleine/rpmbuild/SOURCES/llvm-release-20210419.txt' (No such file or directory) error: test.spec: line 10: Macro %llvm_version failed to expand [...]
In order to work around this error one can fence the expansion of the llvm_version variable with a check for a define:
llvm_version
define
%global yyyymmdd %{lua: print(os.date("%Y%m%d"))} Name: foo Version: 13.0.0 Release: 1 Summary: Foo License: Foo Source0: https://github.com/kwk/llvm-project/releases/download/source-snapshot/llvm-release-%{yyyymmdd}.txt %if !0%{?____in_spectool} %global llvm_version %{lua: print(io.lines(rpm.expand("%{SOURCE0}"))())} %{echo: llvm_version=%{llvm_version}} %endif %description My Description
Then you can download the source files using this invocation of spectool:
$ rm -vf ~/rpmbuild/SOURCES/llvm-release-2021*.txt && spectool -R -g --define "____in_spectool 1" test.spec Downloading: https://github.com/kwk/llvm-project/releases/download/source-snapshot/llvm-release-20210419.txt 100% of 7.0 B |######################################################################################################| Elapsed Time: 0:00:00 Time: 0:00:00 Downloaded: llvm-release-20210419.txt
I'm asking if spectool can provide such a define on it's own. Then an RPM spec file can protect itself from being misinterpreted by spectool. I would love to see this change in spectool and not in the invocation of spectool. I hope this makes sense.
Well, part of the point of the spectool rewrite in rpmdevtools v9 is that now we rely on RPM's own parsing of the spec file. So if it's failing in rpmdev-spectool, chances are pretty good that you goofed in the spec file itself.
rpmdevtools
rpmdev-spectool
I don't particularly want to add stuff like this into rpmdev-spectool because it makes it easier for people to do weird things in spec files.
Oh wait, this is a different spectool, whoops. :sweat_smile:
Not sure if you mean this version but the error is the same with rpmdev-spectool v1.1.0
rpmdev-spectool v1.1.0
It's not to weird to consume a file with lua, is it?
Well, part of the point of the spectool rewrite in rpmdevtools v9 is that now we rely on RPM's own parsing of the spec file. So if it's failing in rpmdev-spectool, chances are pretty good that you goofed in the spec file itself. Not sure if you mean this version but the error is the same with rpmdev-spectool v1.1.0
I don't mean this version. This version works differently from the one in rpmdevtools. I just misread because I'm also subscribed to this project. :sweat_smile:
I second this change. A potential implementation (using the same convention as clang for the macro name) could be:
diff --git a/spectool b/spectool index 4c6069b..2cc4583 100755 --- a/spectool +++ b/spectool @@ -35,7 +35,7 @@ dbprint = None USER_AGENT = 'spectool/' + __version__ -DEFINES = collections.OrderedDict() +DEFINES = collections.OrderedDict(__spectool__=1) # Sure wish I had Python 3.5's subprocess.run(), so here's a hacked one. class CompletedProcess(object):
This is all pretty confusing to me because I created this package ages ago to house a rewrite of spectool that as far as I know never went anywhere and other rewrites from other people ended up being the ones that were used. If you're having a problem with a version of spectool that's actually in Fedora somewhere, this probably isn't the right place to file a bug.
Metadata Update from @tibbs: - Issue close_status updated to: Invalid - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.