Comments for dynamically read spec parts missing from RPMTAG_SPEC

[mlschroe]

There is a Reading... line in the query output if a buildsystem is used:

$ rpmspec -q --srpm --requires /.build.packages/SOURCES/gnome-calculator.spec
Reading /var/tmp/rpm-tmp.2tNKgo
fdupes
itstool
meson >= 0.52.0
mpc-devel
mpfr-devel
rpm_macro(meson_buildrequires)
vala

This message is printed by parseSpecParts(), called from parseBuildsystem(). The easiest fix is probably to not print the notice if stage == PARSE_BUILDSYS.
But maybe parseBuildsystem() should not call parseSpecParts() at all, because the filename is fixed and no globbing should be done.

[pmatilai]

This is actually already fixed in git master and on it's way to 4.20.1 too, see commit bf2c1c3

Of course such output should go to stderr, not stdout no matter what the verbosity level, sigh.
I agree maybe calling parseSpecParts() is not the best thing there because it doesn't need the globbing, but then I wanted it to share the error messages and stuff. Looks liek there should be another internal helper to handle that.

[mlschroe]

Argh, I looked at the old parseSpecParts.c instead of parseSpecParts.cc by mistake. Sorry for the noise.
(I wonder why git did not delete the old files...)

[pmatilai]

No worries, and you have a point.

I just realized that the random pathname ends up in the parsed spec because that's what parseSpecParts() intentionally adds, making the src.rpm of any spec using Buildsystem non-reproducible because this then ends up in RPMTAG_SPEC:

            snprintf(spec->fileStack->readBuf, spec->fileStack->readBufLen,
                     "# Spec part read from %s\n\n", argv[i]);

So we can use this ticket to address that issue instead.

[pmatilai]

Hmm, except that it doesn't, actually. The sprintf() doesn't reach spec->parsed because it happens outside the usual route.
But in that case there's another (minor) bug: for dynamically parsed specs the "# Spec part read from" apparently doesn't end up in the parsed + saved spec as it should.

[pmatilai]

Hmm, the sprintf() seems fishy overall: it outputs to the readBuf but doesn't update the pointer buffer pointer, so that comment will just get overwritten by the actual file read. AFAICS.