Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
> 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 value I mildly disagree with. I looked at https://reproducible-builds.org/specs/source-date-epoch/ a bit now, for the first time ever. Among other things, there's > Build processes MUST use this variable for embedded timestamps in place of > the "current" date and time. So if rpm is supposed to honor this spec, package buildtime MUST be set from SOURCE_DATE_EPOCH if its set. And from there, we get to the point that you can just use RPM_BUILD_TIME for any timestamps, you don't need to differentiate between the two. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1968421934 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 (Issue #2894)
@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: ___ 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 (Issue #2894)
> 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* assumed reproducability to mean. This just goes to point out how completely different expectations people have. No wonder having a meaningful discussion about reproducable packages always seems so hard :smile: > and `OPTFLAGS` and `PLATFORM` are often different because a "random" noarch > package is selected. If you have to strip/ignore/treat-in-a-special-way those > fields, then it doesn't make much difference to also handle `BUILDTIME` and > `BUILDHOST` in the same way. We have to strike a balance between having > useful metadata and ease of reproducibility. Since bit-for-bit > reproducibility is impossible with signatures, then I think the current > balance of using real `BUILDTIME` and `BUILDHOST` is good. ...but okay if we start down the filtering road (I don't disagree, I just clearly don't know what everybody's asssumptions are), then we arrive at this old discussion that never really went anywhere: https://github.com/rpm-software-management/rpm/discussions/2023 Which of course turns the discussion into "which tags should be filtered", and because I'm quite sure not everybody thinks "release" is one of them, just for example. Having a written definition of what "reproducability" means would help driving towards that goal. People clearly have very, very different ideas about it. It's good to have this discussion, but as discussion is what this is, I'm moving this there. Once something concrete emerges, we can open ticket(s). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2894#issuecomment-1968407078 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)
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 unpacking the sources, this is the timestamp to use. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1967741345 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 (Issue #2894)
> 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 distro create different tradeoffs, and different people want to strike the balance between useful metadata and ease-of-reproducibility. Even with the 4 options listed above, Fedora and OpenSUSE disagree on two. In Fedora, we had a discussion about setting `%use_source_date_epoch_as_buildtime 1` and setting a fake `%_buildhost` value and many people were against. People find those informations useful, and very convenient to have them directly in the rpm, even though in they could be extracted from the build system in other ways. So this approach was abandoned, as you know, and we still have `%use_source_date_epoch_as_buildtime 0` and use real hostnames. As @Conan-Kudo mentioned above, we have to strip metadata *anyway*. At least `HEADERIMMUTABLE`, `SIGSIZE`, `SIGMD5`, `SHA1HEADER`, `SHA256HEADER` are "irreproducible", and `OPTFLAGS` and `PLATFORM` are often different because a "random" noarch package is selected. If you have to strip/ignore/treat-in-a-special-way those fields, then it doesn't make much difference to also handle `BUILDTIME` and `BUILDHOST` in the same way. We have to strike a balance between having useful metadata and ease of reproducibility. Since bit-for-bit reproducibility is impossible with signatures, then I think the current balance of using real `BUILDTIME` and `BUILDHOST` is good. > We should not use clamping mtimes, outright setting them has fewer > possibilities for errors (like incorrect clock). Please, no. As @Conan-Kudo wrote above, this has clear downsides, because it forces constant churn between rebuilds. But it also destroys useful metadata, for example timestamps in documentation that specifies when the file was last modified. I'm sure there's a million other examples. And I find the worry about incorrect clocks rather unconvincing. In the current era of signatures being checked all the time, a build system or a developer making releases with a completely wrong time would create huge problems. If you find a case like this, fix it at the source, instead of forcing a heavy-weight workaround. > My understanding is that @mlschroe prefers to have $SOURCE_DATE_EPOCH_MTIME > set the build time and if it is set rpm would ignore but pass through > $SOURCE_DATE_EPOCH. I don't think this has been thought through. `$SOURCE_DATE_EPOCH` now has the meaning of "the timestamp of the sources", i.e. the single timestamp that defines the inputs to the build. We can clamp all the files that are created after that timestamp to `$SOURCE_DATE_EPOCH` because we know that all those files are created from the original inputs, so their timestamps are not important, because they are reproducible and we can recreate them exactly independently of time. So `$SOURCE_DATE_EPOCH` has a clear meaning and any timestamps later than that are redundant. The second problem is that we have a timestamp that is used to clamp mtimes. If we introduce a second timestamp and use that for clamping, we have to redesign/fix/update everything to use the new timestamp. Once we have gone through that churn, we are in almost the same situation, except that the variable name is different (and we also have a two variables with a slightly different meaning). All that said, I think it's fine if a way to e.g. add new options how to clamp/set mtimes and whatnot. But please make those opt-in, so that different distros that have slightly different approaches can make their choices. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2894#issuecomment-1967726605 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)
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: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1967579370 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] Expose build time to package build scriptlets via $RPM_BUILD_TIME (PR #2933)
👍 -- 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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] No build directives in generated spec parts (PR #2917)
@ffesti pushed 2 commits. 69b688ed04e78f40c9565f570e5fb72b8f64a057 Add parseStages enum b1eb41516fd8a6674f334502f98a99d3aa7f9a58 No build directives in generated spec parts -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2917/files/55c12c3e283d39e412642e317cd89a2a5d577e0a..b1eb41516fd8a6674f334502f98a99d3aa7f9a58 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] rpm2archive man narrative fix (passage about rpm dependency) (PR #2931)
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 mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support for 'm' in sysusers file? (Issue #2816)
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: https://github.com/rpm-software-management/rpm/issues/2816#issuecomment-1966612030 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] Expose build time to package build scriptlets via $RPM_BUILD_TIME (PR #2933)
@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 build scriptlets, (at least) the following +rpm-specific environment variables are set: + +Variable| Description +--- +RPM_ARCH| Architecture of the package +RPM_BUILD_DIR | The build directory of the package +RPM_BUILD_NCPUS | The number of CPUs available for the build +RPM_BUILD_ROOT | The buildroot directory of the package +RPM_BUILD_TIME | The build time of the package Good point, thanks. Fixed in the latest push. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2933#discussion_r1504256038 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] Expose build time to package build scriptlets via $RPM_BUILD_TIME (PR #2933)
@pmatilai pushed 1 commit. 27d11c2dd1524bd22eca08d45585280a57b4c65b Expose build time to package build scriptlets via $RPM_BUILD_TIME -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2933/files/e280635af926f390d828c3fe49a2e7c7588c57c8..27d11c2dd1524bd22eca08d45585280a57b4c65b 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)
> 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 uses that as the universal truth. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1966565548 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] Clean up Runtime scriptlets section in manual (Issue #2867)
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: https://github.com/rpm-software-management/rpm/issues/2867#issuecomment-1966548956 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)
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. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1966542078 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)
@keszybz pushed 1 commit. 1fac2eab0fd823817b52b53891f27d6cf2aacf43 Set git commit dates based on $SOURCE_DATE_EPOCH or $RPM_BUILD_TIME -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930/files/0caffe0df7e5d3ab1d510eeb226381dc831fe0ec..1fac2eab0fd823817b52b53891f27d6cf2aacf43 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] Expose build time to package build scriptlets via $RPM_BUILD_TIME (PR #2933)
@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 build scriptlets, (at least) the following +rpm-specific environment variables are set: + +Variable| Description +--- +RPM_ARCH| Architecture of the package +RPM_BUILD_DIR | The build directory of the package +RPM_BUILD_NCPUS | The number of CPUs available for the build +RPM_BUILD_ROOT | The buildroot directory of the package +RPM_BUILD_TIME | The build time of the package This should specify format/units, i.e. seconds since since the epoch. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2933#pullrequestreview-1903487383 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] Expose build time to package build scriptlets via $RPM_BUILD_TIME (PR #2933)
@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: ___ 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)
> 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: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1966507854 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] Non parametric macro inconsistency (Issue #2932)
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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Non parametric macro inconsistency (Issue #2932)
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 mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add --list-keys and --delete-key to rpmkeys (PR #2921)
@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, "gpg-pubkey-", 11)) {
+ char * gpgarg = rpmExpand("gpg-pubkey-", *arg, NULL);
No idea why moving the code elsewhere didn't solve the issue...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2921#discussion_r1504149610
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] Add --list-keys and --delete-key to rpmkeys (PR #2921)
@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 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] Expose build time to package build scriptlets via $RPM_BUILD_TIME (PR #2933)
@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: ___ 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)
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: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1966414614 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] support reproducible automatic rebuilds (PR #2880)
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. But that doesn't change anything about handling `$SOURCE_DATE_EPOCH`, because the presumption is that the date doesn't matter because you're fixing it to a fake time anyway. So this is solving the wrong problem anyway. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1966407685 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)
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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Expose build time to package build scriptlets via $RPM_BUILD_TIME (PR #2933)
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 rpm-specific environment variables in build scripts * Expose build time to package build scriptlets via $RPM_BUILD_TIME -- File Changes -- M build/build.c (5) M docs/manual/spec.md (19) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2933.patch https://github.com/rpm-software-management/rpm/pull/2933.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2933 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] Non parametric macro inconsistency (Issue #2932)
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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Non parametric macro inconsistency (Issue #2932)
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 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)
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: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1966336509 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] Non parametric macro inconsistency (Issue #2932)
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 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] support reproducible automatic rebuilds (PR #2880)
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 straightforward, reliable and easy to understand way to deal with avoiding unnecessary updates. It's not *free* of course but nothing is. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1966195690 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] support reproducible automatic rebuilds (PR #2880)
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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] support reproducible automatic rebuilds (PR #2880)
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 system that you have, and makes very strong assumptions about which mtime should be used where. Right now we have the concept of the $SOURCE_DATE_EPOCH, and it is a *single* timestamp that says "this is when the build happened", and both the packager and the user can understand it. This means that the same value is used in many places: embedded build metadata, headers and footers in build docs, the changelog, file mtimes or delivered files, etc. With the patch, we have two timestamps, with ad-hoc rules which to use where. Without considering further technical details, I think this increased complexity would never be worth it. At a more technical level, I think in particular this would break Python .pyc file caching: Python uses cache invalidation where it compares the mtime on the .py file with the timestamp-of-the-original-py-file embedded in the .pyc file. For packages, the .pyc file is created during build and stored in the package. IIUC, you want to use $OLD_SOURCE_DATE_EPOCH for "build scripts", i.e. .pyc files would embed $OLD_SOURCE_DATE_EPOCH, but actually deliver files with mtimes set to (new) $SOURCE_DATE_EPOCH. This means that Python would consider the .pyc file stale and always try to rebuild it. (If, OTOH, you use the mtimes with $OLD_SOURCE_DATE_EPOCH in delivered files, then the user loses an important property that the mtime of compiled files corresponds to the package build.) > OpenSUSE does not change the changelog for the rebuild I think this is a fundamental error. You're doing a rebuild because something *important* changed. When the user gets this newly-built package, they really should know that this is an updated version with the *important* thing. So if there's a %changelog at all, stuff like version bumps and rebuilds for important environment changes are the foremost things to put there. But if the changelog changes, the package is not the same, and in general, I think it doesn't make sense to twist everything to try to avoid updating the package. I would suggest a different approach: if you have the environment change, do a *test rebuild* with no changelog change and the original $SOURCE_DATE_EPOCH. If the result is bit-for-bit identical, record this in a log somewhere and throw away the build, since the users don't need to update. If the result shows any changes, record a changelog entry and rebuild with the new $SOURCE_DATE_EPOCH and push that out to users. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1966099057 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] RPM uses pragma case_sensitive_like which is deprecated from sqlite 3.44 (Issue #2925)
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: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM uses pragma case_sensitive_like which is deprecated from sqlite 3.44 (Issue #2925)
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 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] Introduce an rpm-controlled per-build directory (PR #2885)
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 corresponding macros from the main macros file too. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1966037547 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] Introduce an rpm-controlled per-build directory (PR #2885)
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: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1966022457 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] Introduce an rpm-controlled per-build directory (PR #2885)
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: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1965986231 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
