[Rpm-maint] [rpm-software-management/rpm] build: reword "%changelog is missing" (PR #2943)
Despite openSUSE packages having a %changelog section at all times, rpm throws this error. Turns out it's just terribly worded. Fix that. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2943 -- Commit Summary -- * build: reword "%changelog is missing" -- File Changes -- M build/build.c (4) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2943.patch https://github.com/rpm-software-management/rpm/pull/2943.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2943 You are receiving this because you are subscribed to this thread. Message ID:___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#pullrequestreview-1911698628 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
Sounds good to me. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1973616134 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
> Oh, wouldn't we need these fixups for all the VCS backends, not just Git? Theoretically, yes. In practice, nobody cares. I have never seen any of the other macros used. Once we have a version that is acceptable, I'd be happy to submit a follow-up that extends the same logic to other systems, if they support it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1973553115 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
Oh, wouldn't we need these fixups for all the VCS backends, not just Git? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1973534254 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
> @DemiMarie suggested a while back that if the non-signature aspects of the > package are reproducible, then you can combine the signature of the original > package with rebuilt package, and _that_ should be able to reproduce the > package. Yes, in principle you could. But it still wouldn't satisfy the definition on reproducible-builds.o because they require an **independent** rebuild to produce the same output. To transplant the signature, you'd need access to the "build outputs" from the first rebuild. Also, meh, we would get "bit-for-bit identical output", but at a very heavy price: we need access to the original build artifacts **and** we need some complicated tool to transplant signatures. Compared to this, the current state where we can do with access to the orginal build metadata (i.e. buildroot contents listings, not the output rpms) and use existing fairly simple tools to ignore parts of rpms seems like a better tradeoff. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1973320489 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
I don't think it's a good idea to offer. I am not convinced these knobs are a good idea for RPM to expose for any reason, especially reproducibility. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8643933 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
I am aware of some tools that use `RPMTAG_BUILDTIME` to sort packages in various situations, especially if they have the same NVRA (ie. rebuilds). It is also useful in diagnostic purposes when trying to figure out a factor of breakage. I would rather not falsify this tag. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8643922 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
Yes, I think both are worthwhile. But they must be opt-in. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8643884 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
I think this all has drifted away from the initial proposal. The goal was to be able to improve reproducibility of a given rpm by: - adding a way to specify the buildtime - adding an option to clamp the file mtimes to the buildtime Disregarding the implementation details, do you all think this is worthwhile to have? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8643827 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
Ah, you're right that if the builder and rebuilder aren't the same person (which, really, is the primary use case of reproducible builds) then you won't be able to reproduce the package. @DemiMarie suggested a while back that if the non-signature aspects of the package are reproducible, then you can combine the signature of the original package with the signature of the rebuilt package, and *that* should be able to verify correctly as if it was completely reproduced. https://github.com/rpm-rs/rpm/issues/156#issuecomment-1575994196 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1973291699 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow customizable default of RPMBUILD_RMBUILD in rpmbuild (--noclean) (Discussion #2942)
Ah, then yes, that would be what I were looking for. But because quite unintuitive name I have never tried to use it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2942#discussioncomment-8643683 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow customizable default of RPMBUILD_RMBUILD in rpmbuild (--noclean) (Discussion #2942)
rpmbuild -bi does run %check, and it also runs the usual files checks. Like I said, it basically does everything but produce binaries. `fedpkg install` (it's a weird name for what it does, yes) is the fedpkg equivalent. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2942#discussioncomment-8643366 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow customizable default of RPMBUILD_RMBUILD in rpmbuild (--noclean) (Discussion #2942)
seems ``rpmbuild -bl`` would be ideal for me. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2942#discussioncomment-8643342 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow customizable default of RPMBUILD_RMBUILD in rpmbuild (--noclean) (Discussion #2942)
I want to check unit tests are passing in my builds. Also I want to check %files are found and packaged, but most of time I will delete built rpms without installing them. Afaik *fedpkg* does not allow to use rpmbuild -bi alternative, but has -bb via local build :) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2942#discussioncomment-8643325 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow customizable default of RPMBUILD_RMBUILD in rpmbuild (--noclean) (Discussion #2942)
If you don't care about binaries then why are you building them in the first place? 'rpmbuild -bi' and will do all the same build steps, only it wont procuce packages or clean the build, because it's *intended* for that sort of work. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2942#discussioncomment-8643293 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow customizable default of RPMBUILD_RMBUILD in rpmbuild (--noclean) (Discussion #2942)
Tags on mentioned commit say: Follows: rpm-4.17.0-alpha Precedes: rpm-4.19.0-alpha Just tried it on rpm-build-4.16.1.3-29.el9.s390x, where --noclean is not necessary. This is not about deleting buildroot *before* the build, but *after successful* build. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2942#discussioncomment-8643221 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow customizable default of RPMBUILD_RMBUILD in rpmbuild (--noclean) (Discussion #2942)
> Before commit > https://github.com/rpm-software-management/rpm/commit/b34333fa021c0ee7215714eeef96d1a2843ea08e, > rpmbuild has by default kept built artifacts. RPM has deleted the buildroot tree by default since RPM 4.6. If it wasn't doing that before, that's a bug. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2942#discussioncomment-8643193 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow customizable default of RPMBUILD_RMBUILD in rpmbuild (--noclean) (Discussion #2942)
In fact, I might want to delete built rpms instead. Usually I do not need them anyway, because I do local builds usually just o test something with built version. I need builddir, but not locally generated rpms. But that would be other topic. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2942#discussioncomment-8643121 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Allow customizable default of RPMBUILD_RMBUILD in rpmbuild (Discussion #2942)
**Is your feature request related to a problem? Please describe.** Before commit b34333fa021c0ee7215714eeef96d1a2843ea08e, rpmbuild has by default kept built artifacts. I had often used it to run upstream test suite of bind package, which needs first setup made by root. Therefore it could not be done during normal build. Also it takes long. When something fails there, I may need use gdb or other debug steps to find a solution. It helps me a lot if the gdb can reuse my prepared settings, not vanilla mock environment. **Describe the solution you'd like** I would like to be able to change default of --clean for rpmbuild -bb or -ba. I want to override it on my machine, so it by default keeps built artifacts for subsequent testing or debugging. I would like to avoid the need to append --noclean to every build. Instead some kind of configuration change to some file, done only once on my system. **Describe alternatives you've considered** Making alias, which would add rpmbuild --noclean parameter to everything might work. But such alias would not be used, if I use rpkg variants such as fedpkg to build my package. I would have to make aliases for that also. But there it will become complicated, rpmbuild options to it need to be last arguments. I would have to make special shell wrapper. That makes it unnecessary complicated. Just default change would work much better. **Additional context** I haven't found a way to configure the default. It does not seem to be possible to change default value in ~/.rpmmacros or any configuration file. Deleting the results is much faster than recreating it every time I forgot --noclean appended. Opinions on this topic? Please skip the phase use mock instead. It does not work the best for me. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2942 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
I did not mean to alter signing time - but keep it as it is (it is dropped by delsign anyway), while changing "Build Date" instead to something that does not vary in (changeless) rebuilds. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8641508 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
I think the signature must give the real date of when the signature was actually made. Setting a fake date would be very very icky, undermining the trust in the signing process and the holders of the signing key used in such a manner. At the more technical level, keys have a creation time, e.g. for Fedora the keys are created a few months in advance of the release (RPM-GPG-KEY-fedora-rawhide-x86_64 has Public key creation time - Tue Jan 24 22:22:52 CET 2023). This means that those keys cannot be used to create valid signatures for older packages, but at various points there certainly are packages that haven't been touched and have a SOURCE_DATE_EPOCH older than they key creation date. Also, at least in Fedora, packages are resigned with a newer signature for a new release. (E.g. a .f39 or .f40 package, when downloaded from the F41/rawhide repository, is not rebuilt, but is resigned with the F41 key.) So we *need* a signing time that is separate from BUILDTIME. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8641433 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
> > A signed rpm build can never be "reproducible" according to their current > > definition. > > Theoretically you could just ensure that the RPM signature uses the same > `SOURCE_DATE_EPOCH` timestamp rather than the current time I generally assume that the private key used for signing is not available to the rebuilder. If it *is* available, the whole signature isn't worth very much ;) And the rb.o definition requires the rebuild to be completely independent, i.e. the rebuilder is supposed to reproduce a bit-for-bit identical output only with access to the sources. So playing with the signature time wouldn't help to achieve a reproducible build according to the original definition. Also, I don't think that setting a fake time on the signature is something that should be done. It's feels wrong, and would probably cause many different issues. For example, the key might have some initial validity, so probably we wouldn't even be able to sign packages with sufficiently old `$SOURCE_DATE_EPOCH`. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1972920932 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
When I normalize BUILDTIME with `%use_source_date_epoch_as_buildtime`, the signature still gives the real date. Is there a value in keeping both? e.g. [this package](https://build.opensuse.org/package/show/home:bmwiedemann:reproducible/strip-nondeterminism) `rpm -ql` has ``` Signature : RSA/SHA256, 2024-02-26T12:00:49 UTC, Key ID 8adc26dbb49c2121 Source RPM : strip-nondeterminism-1.13.1-33.9.src.rpm Build Date : 2023-07-28T16:19:49 UTC ``` Not overriding BUILDHOST is fine as it still allows easy verification. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8640953 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
