> > 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
Cool, thanks. We'll give this a go in Fedora as soon as it becomes available by
doing some rebuilds of official koji builds. I hope it works as expected, and
if not, we can always adjust.
--
Reply to this email directly or view it on GitHub:
As for the other backends, I don't bother. If somebody files a PR/ticket on
those, then we'll at least know somebody is actually using them. And if not...
Oh and thanks for the patch!
--
Reply to this email directly or view it on GitHub:
Merged #2930 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2930#event-11994504993
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Okay... my dislike of how reprodu*cible* (see, the old dog learned a trick
:laughing: ) builds are configured in rpm is really out of scope for this PR.
It's not like I disagree with what this does.
--
Reply to this email directly or view it on GitHub:
@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
> 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,
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
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
> > 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
>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 - it's a bit icky,
but it works.
--
Reply to this email directly or
That spec was written by Debian maintainers and it's heavily slanted towards
some Debian concepts and needs some adaptation to the rpm world. In particular,
their definitions are incompatible with embedded signatures. A signed rpm build
can never be "reproducible" according to their current
> SOURCE_DATE_EPOCH is exactly the field that should be used here. That
> variable says when the sources were last modified, so if we do a fake commit
> when unpacking the sources, this is the timestamp to use.
I totally agree that's the timestamp to use, it's just the means of getting the
I wrote a longer reply in
https://github.com/rpm-software-management/rpm/issues/2894… But even ignoring
the discussion there, I think SOURCE_DATE_EPOCH is **exactly** the field that
should be used here. That variable says when the sources were last modified, so
if we do a fake commit when
Locking down the stored build time in the rpm headers to `SOURCE_DATE_EPOCH`
can have other undesirable side-effects, so generally I wouldn't want that to
be a thing for Fedora or any distribution, really.
--
Reply to this email directly or view it on GitHub:
> Buildtime cannot be overriden?
Buildtime would be SOURCE_DATE_EPOCH for reproducable builds, no? See the
discussion in https://github.com/rpm-software-management/rpm/issues/2894 - its
converging towards the notion that you select the source where buildtime is
set, and then everything else
I changed the patch to use $RPM_BUILD_TIME as fallback, as suggested by Neal.
But I think $SOURCE_DATE_EPOCH must remain the primary source for this. When it
is set, then we set various mtimes and other stuff to it, and it would be very
strange to use something different for the repo commits.
@keszybz pushed 1 commit.
1fac2eab0fd823817b52b53891f27d6cf2aacf43 Set git commit dates based on
$SOURCE_DATE_EPOCH or $RPM_BUILD_TIME
--
View it on GitHub:
> I'd rather use rpm's buildtime here
buildtime is not clamped? We had a discussion about this in
https://github.com/rpm-software-management/rpm/issues/2603 and it was
explicitly rejected.
--
Reply to this email directly or view it on GitHub:
If we're not clamping the build-time but want the commits to be clamped (which
is Fedora's configuration), then this is the way we need to do it. I do think
that if SOURCE_DATE_EPOCH isn't set, we should clamp to RPM_BUILD_TIME though.
--
Reply to this email directly or view it on GitHub:
Just pushed a PR to make the buildtime available to scriptlets: #2933
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1966395641
You are receiving this because you are subscribed to this thread.
Message ID:
I'd rather use rpm's buildtime here, which for reproducable builds would be set
from SOURCE_DATE_EPOCH. All packages have a buildtime so you don't need to
conditionalize it.
--
Reply to this email directly or view it on GitHub:
Another case which becomes reproducible with this patch: podman, and presumably
any go package. Go builds include `vcs.revision=…` `vcs.time=…` somewhere in
binary file metadata and with this patch (plus a few others to remove
intentional randomness), `podman-5.0.0~rc3-3.fc41.x86_64.rpm`
When %autosetup -S git is used, a bunch of git commits are created. Without an
override, their metadata will include the current time. Many projects include
the git hash of HEAD in the build information, which means that the build
result is not reproducible. Since were creating a scratch repo
26 matches
Mail list logo
