> 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
@pmatilai converted this issue into discussion #2934.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2894#event-11947622981
You are receiving this because you are subscribed to this thread.
Message ID:
> As @Conan-Kudo mentioned above, we have to strip metadata _anyway_. At least
> `HEADERIMMUTABLE`, `SIGSIZE`,
> `SIGMD5`, `SHA1HEADER`, `SHA256HEADER` are "irreproducible"
Wait, what? If those differ then the packages do differ, so its not actually
bit-per-bit identical. Which is what *I've*
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
> a coherent (re)design for reproducible builds, where you basically just flick
> it on and be done with it
I agree that the current set of options is a bit ad-hoc. But I think it's
completely unrealistic to achieve a single switch, because different build
systems and ways of managing the
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:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2933#issuecomment-1967314022
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
@ffesti pushed 2 commits.
69b688ed04e78f40c9565f570e5fb72b8f64a057 Add parseStages enum
b1eb41516fd8a6674f334502f98a99d3aa7f9a58 No build directives in generated spec
parts
--
View it on GitHub:
thanks @pmatilai !
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2931#issuecomment-1966723326
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
On a related note, we should probably also generate a group require on a case
like this:
`u cyrus76:mail"Cyrus IMAP Server" /var/lib/imap
/sbin/nologin`
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> @@ -476,6 +476,25 @@ If the main section exists, it must come first to avoid
> ambiguity.
Otherwise, append and prepend can be used in any order and multiple
times, even if the corresponding main section does not exist.
+During the execution of
@pmatilai pushed 1 commit.
27d11c2dd1524bd22eca08d45585280a57b4c65b Expose build time to package build
scriptlets via $RPM_BUILD_TIME
--
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
While at it, I realized the whole [Runtime
scriptlets](https://rpm-software-management.github.io/rpm/manual/spec.html#runtime-scriptlets)
section needs to be rewrtiten and updated so I'll do that as part of this
ticket.
--
Reply to this email directly or view it on GitHub:
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:
@keszybz commented on this pull request.
> @@ -476,6 +476,25 @@ If the main section exists, it must come first to avoid
> ambiguity.
Otherwise, append and prepend can be used in any order and multiple
times, even if the corresponding main section does not exist.
+During the execution of
@keszybz commented on this pull request.
LGTM too.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2933#pullrequestreview-1903483241
You are receiving this because you are subscribed to this thread.
Message ID:
> 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:
True. I'm fine with leaving it the way it is.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2932#issuecomment-1966443986
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2932 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2932#event-11935607092
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
@ffesti commented on this pull request.
> @@ -42,6 +41,20 @@ static struct poptOption optionsTable[] = {
POPT_TABLEEND
};
+static ARGV_t gpgkeyargs(ARGV_const_t args) {
+ARGV_t gpgargs = argvNew();
+for (char * const * arg = args; *arg; arg++) {
+ if (strncmp(*arg,
@ffesti pushed 1 commit.
c33f2943fe01fd629a0beda4efcf2a3b60b1c7f0 Add --list and --delete to rpmkeys
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2921/files/3ae469d7df0755d847fedd7bbc8f7edd6ec13251..c33f2943fe01fd629a0beda4efcf2a3b60b1c7f0
You are receiving this
@Conan-Kudo approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2933#pullrequestreview-1903336269
You are receiving this because you are subscribed to this thread.
Message ID:
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:
I don't think bumping the changelog for rebuilds is actually important, but I
do think that this is still the wrong way to solve it, because we're presuming
that _a rebuild is important_. When rebuilds happen every day for whatever
reason due to dependency churn, they are no longer important.
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:
This is useful for consistently setting timestamps within build scriptlets, in
particular when doing reproducable builds.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2933
-- Commit Summary --
* Document the
Why should the latter return anything else than an error?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2932#issuecomment-1966341489
You are receiving this because you are subscribed to this thread.
Message ID:
There are good reasons to leave it the way it is, I just wanted to point out
that there's a somewhat undocumented difference.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2932#issuecomment-1966339147
You are receiving this because
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:
I stumbled over this:
```
$ rpm --eval '%{?_libdir:foo}'
foo
$ rpm --eval '%{_libdir:foo}'
/usr/lib64
```
Should those two both return `foo`?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2932
You are receiving this because you are
Thanks @keszybz for the detailed and thoughtful comments, that's very much my
sentiments too: sanity dictates there can be only one buildtime for any given
build. Anything else is gaming the system - like I said in my first comment,
trying to eat and keep the cake. A test-build is a
Thank you for the detail about pyc, that is important.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1966164234
You are receiving this because you are subscribed to this thread.
Message ID:
I read this proposal when the ticket was initially created, and I didn't find
it convincing, and now, a few weeks later, I still don't.
This is a very complex solution to a very specific problem. It is very narrowly
tailored to the specific details of the build system and package delivery
Closed #2925 as completed via 233ddeb188544dc76444829c36b42db3e655836f.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2925#event-11932914890
You are receiving this because you are subscribed to this thread.
Message ID:
Oh. I had no recollection whatsoever of that change :flushed:
Indeed, we can then just remove the pragma. Thanks @mlschroe for pointing that
out.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2925#issuecomment-1966052793
You are
After (way too) much mulling over it: BUILDROOT and SPECPARTS names are now
hardcoded in the source, neither of these should be user configurable really
but were so for various historical reasons, such as not having the guaranteed
per-build directory we're adding in this very PR. Removed the
Eh, except that we create our scriptlets, including the one that creates the
builddir, in %_tmppath so we there's a tiny :egg: - :chicken: matter there. Oh
well, maybe later.
--
Reply to this email directly or view it on GitHub:
Yet another use-case: we can override build-time %_tmpdir to something inside
this build area, at which point a build is pretty thoroughly contained within
this one directory where it needs write-permissions.
--
Reply to this email directly or view it on GitHub:
40 matches
Mail list logo
