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: r
@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: __
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 mailin
> 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, i
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: _
> @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 sa
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
Yo
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 ema
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:
_
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
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 yo
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
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/r
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:
___
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 direc
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:/
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 i
> 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 d
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 GitHu
**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
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/discu
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.
> > 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
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/S
24 matches
Mail list logo
