Please file a new issue on that.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1241#issuecomment-1375505207
You are receiving this because you are subscribed to this thread.
Message ID: ___
I found that unfortunately this change makes many of our rpm builds
unreproducible, because our .spec files contain things like `make
%{?_smp_mflags}` and that gets expanded depending on the build machine CPU core
count.
Is there an easy way to disable this or do you have a different proposal o
As a note to self, we could/should probably use RPMFILE_ARTIFACT to flag such
files.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1241#issuecomment-760944532__
Generally speaking it would be great to store more build-time information in
the spec. I’ve been requested to store the buildroot state for debuging and
reproducibility needs, for example.
https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/bc4e6a79355f3a2b73abeea7e5c0e1f53b09579e?br
There was a request years ago (not sure it was tracked in rpm.org trac) for
doing this for reproducible builds, because we want to be able to replay the
exact build environment and settings, and the current way is incomplete.
--
You are receiving this because you are subscribed to this thread.
No, that was simply to support rpmspec --parse. There was a request to add the
spec to the header, or something, someplace, but whether that request was for
the *parsed* spec I don't recall.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or vie
rpmSpecGetSection() returns it when passed RPMBUILD_NONE. Guess adding this to
the API is what you remember even if it has been a while:
`
c38504c4ba build/rpmspec.h (Panu Matilainen 2011-06-17 13:44:39 +0300 78) * As
a special case, RPMBUILD_NONE as section returns the entire spec in
c38504c4ba
With the trend of increasingly dynamic content generation for specs (currently
via complex macros, in future automatic & dynamic sub packages, #329, #1222
etc) the originating spec and the parsed one might differ by hundreds of lines,
making it really hard to grasp how we got from A to B. It see
