Re: [Rpm-maint] [rpm-software-management/rpm] Add support for sysusers group membership lines (PR #2990)
@pmatilai commented on this pull request. > @@ -25,6 +25,9 @@ user/group allocation altogether by using ## Dependencies +Explict group membership (m) will create a dependency on both the user +and the group name. It's a bit weird to have this as the first thing in this section. I'd put it after the more common main file ownership stuff. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2990#pullrequestreview-1978795106 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] RFE: execute rpmbuild tests as a regular user (Issue #3005)
What I mean is rpm's own test-suite: https://github.com/rpm-software-management/rpm/blob/5d4a476d14998f8f7ebc7e0c15a5263ca7803f5d/tests/mktree.oci#L53 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2035694448 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] Enhance requires with version information from the build root. (PR #2372)
As far as I know, the blocking issue here is simply a decision about where to get the version of the library. Among others, options include: 1: the rpm version of the package that owns the library. Not a good solution because I think the maintainers don't want elfdeps to access the RPM DB during the build, and because it'd make interchangeable library implementations much harder. 2: a version string derived from the target of the symlink that ELF files refer to. This requires *some* coordination for interchangeable libraries. It also requires a two-phase rollout in which packages "provide" new capabilities and then later "require" those new capabilities. And once that two-phase rollout is complete, old builds (which might be present in SUSE) can't be used any more. 3: a version string stored in a text file, defaulting to the version of the package that provides the library, but optionally defined by the packagers. Requires no coordination upstream, and supports organic rollout. 4: the same version stored somewhere else. Maybe in an extended attribute. Do extended attributes work properly in environments like mock container builds? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2035549671 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] Enhance requires with version information from the build root. (PR #2372)
> One possible disadvantage: you wouldn't be able to e.g. dnf downgrade xz* I think it's important to differentiate the real binary dependencies from RPM's knowledge of those dependencies. In Fedora 40, it was safe to downgrade xz because libsystemd had been built before xz 5.6. If it had been built after, that might not have been true. xz 5.6 introduced at least one new symbol: `lzma_mt_block_size`. It's not certain that libsystemd would have had a reference to this symbol if it had been built in a build root with xz 5.6, but it could have. And if it did, then reverting to xz-5.4 would have caused everything linked to libsystemd to fail to start. Fedora's maintainers would surely have noticed that, and would have rebuild systemd in a build root with xz-5.4, and pushed that update along with the xz-5.4 downgrade, but hypothetically, users might have decided that only xz was worth updating. If they'd updated only the revert-to-5.4 xz packages, the result would have been a disaster on those systems. But as you point out, if this change was already deployed, then downgrading xz would also downgrade everything that was built against xz-5.6, which would have avoided any users mistakenly breaking everything linked to a hypothetical libsystemd that required symbols in 5.6. So as I see it, the xz downgrade is a really good illustration of why this change is needed. We were lucky that we were able to safely downgrade that package. We should not rely on luck. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2035519467 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] Enhance requires with version information from the build root. (PR #2372)
That's currently possible and can lead to various subtle runtime failures instead. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2035405478 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] RFE: ensure unwritable buildroot during %check (Issue #3010)
I opened https://github.com/rpm-software-management/rpm/issues/3015, which I believe will be much easier to implement. And will gain the same benefit. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2035392608 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] RFE: execute rpmbuild tests as a regular user (Issue #3005)
> we're running the entire test-suite as root. I believe this is not true. I see no code in rpmbuild that would elevate UID to root. Nor any consolehelper. Nor setuid bits. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2035386167 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] RFE: short-circuit to %check phase (Issue #3015)
We can `--short-circuit` to almost any phase. But we cannot short circuit directly to `%check` phase. This should be trivial to implement and would allow to implement isolation of `%check` phase in Mock https://github.com/rpm-software-management/mock/issues/1352 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3015 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] Enhance requires with version information from the build root. (PR #2372)
One possible disadvantage: you wouldn't be able to e.g. `dnf downgrade xz*` without also downgrading everything that was built against xz. (You might also consider that an advantage, but most users probably wouldn't.) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2035358830 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 support for sysusers group membership lines (PR #2990)
@ffesti pushed 1 commit. 8558a2c2bf06c4b89a4ea59b50cedb80b00c6d87 Add support for sysusers group membership lines -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2990/files/81acc230b3b7c84b519e4bca4aee13bdbf9952b2..8558a2c2bf06c4b89a4ea59b50cedb80b00c6d87 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 support for sysusers group membership lines (PR #2990)
OK, fixed the issue in the code and made sure the test cases actually checks for group membership. Added a bit to the docs and the commit message. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2990#issuecomment-2034875120 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 support for sysusers group membership lines (PR #2990)
@ffesti pushed 2 commits. 1e4e9648b114131b8a872878ef8c5cc5739efaf9 Re-Word User / Group handling a bit 81acc230b3b7c84b519e4bca4aee13bdbf9952b2 Add support for sysusers group membership lines -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2990/files/e96d496349e191e4b97d07f74ce477edd125bdfc..81acc230b3b7c84b519e4bca4aee13bdbf9952b2 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] PGP key identifiers use binding signature's creation time, not certificate creation time (Issue #2004)
...since the keyring changes done in 2008. I'm so out of touch with rpm... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-2034700620 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] PGP key identifiers use binding signature's creation time, not certificate creation time (Issue #2004)
OTOH rpm only looks at the keyid to check if the key is already present since some time... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-2034511695 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] Make -C the default for BuildOption(prep) (Issue #2998)
Maybe not the greatest example but at least something: https://github.com/rpm-software-management/rpm/commit/5d4a476d14998f8f7ebc7e0c15a5263ca7803f5d -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2998#issuecomment-2034434069 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] Make -C the default for BuildOption(prep) (Issue #2998)
Doubly more embarrassing as you mentioned that in the ticket description :laughing: Will fix. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2998#issuecomment-2034411616 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] Make -C the default for BuildOption(prep) (Issue #2998)
Oh, thanks for pointing that out! I didn't even remember we have that in the documentation (although it was written by me, so ... age doesn't come alone as they say around here) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2998#issuecomment-2034408525 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] Make -C the default for BuildOption(prep) (Issue #2998)
Thanks. I noticed the `BuildOption(prep)` documentation was not updated in that PR. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2998#issuecomment-2034393793 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] Make it possible to evaluate arbitrary macros in the context of a given spec file (Discussion #3008)
After a bit of pondering, filed https://github.com/rpm-software-management/rpm/issues/3014 instead, we'll revisit the aliases with this is fixed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3008#discussioncomment-8995444 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 building rpm without OpenPGP support (PR #2984)
I know the split is somewhat painful this way, but it was the least painful (or only) way I could see to accomplish this within reasonable time/effort. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2034208979 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 building rpm without OpenPGP support (PR #2984)
Ah, I missed that. Then please ignore me ;-) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2034198154 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 building rpm without OpenPGP support (PR #2984)
Oh, I guess I wasn't clear: sure rpm-sequoia supports and exports all the digest functionality rpm needs. What I mean is that it does NOT support using libgcrypt/openssl from rpm side to do that. libgcrypt/openssl digest support in rpm is only for the case where rpm-sequoia is not available. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2034189934 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 building rpm without OpenPGP support (PR #2984)
Why wouldn't it make sense? Sequoia needs to do digesting anyway to verify the signatures, it might as well expose the functionality. Securitywise it is bad design if two implementations are used. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2034182714 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 building rpm without OpenPGP support (PR #2984)
The sole reason for this exercise is to be able to build rpm *without* rpm-sequoia. rpm-sequoia doesn't support external digest, and wouldn't make much sense for it to do so. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2034170127 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] rpmspec: Use NEVRA for binary packages queries (PR #2995)
Merged #3012 instead -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2995#issuecomment-2034120680 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] rpmspec: Use NEVRA for binary packages queries (PR #2995)
Closed #2995. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2995#event-12338936477 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] `rpmspec` default output unexpected (Issue #2819)
Closed #2819 as completed via dc47a50c6345a25b861305d8aa8ae464098834ff. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2819#event-12338919876 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] Ensure binary and source headers are identified as such after parse (PR #3012)
Merged #3012 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3012#event-12338919518 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 building rpm without OpenPGP support (PR #2984)
You really should use Sequoia for digesting. It makes no sense to use openssl/libgcrypt in rpm and something else in sequoia. If it's not already exposed, can you please add expose digesting functionality in Sequoia? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2034101985 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] PGP key identifiers use binding signature's creation time, not certificate creation time (Issue #2004)
It needs to get a new release when the key us updated, otherwise the rpm --import will just do nothing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-2034037416 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] PGP key identifiers use binding signature's creation time, not certificate creation time (Issue #2004)
I.e. pgpDigParamsCreationTime() is somewhat misnamed, it does not the key creation time. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-2033982940 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] PGP key identifiers use binding signature's creation time, not certificate creation time (Issue #2004)
This somehow slipped my radar. The "time" used in rpm is not supposed to be the key creation time, but the last time the key was changed. I don't think you should break this. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-2033958348 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] PGP key identifiers use binding signature's creation time, not certificate creation time (Issue #2004)
Reopened #2004. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2004#event-12337884161 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] Make -C the default for BuildOption(prep) (Issue #2998)
Closed #2998 as completed via #3002. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2998#event-12337492251 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] Default to automatic build directory path on declarative builds (PR #3002)
Merged #3002 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3002#event-12337492048 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 support for setting the build time and clamping to the build time (PR #2944)
Oh and update (some of) the tests to use the new macros, optimally add a new one for the clamp_to_buildtime behavior. The above nits aside, I'm not going to say no to a reproducible builds patch that appears to have consensus from everybody :sweat_smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2944#issuecomment-2033754048 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 ability to specify extra command after %setup (PR #2961)
After a few nights sleep - sorry but no. It'd be this strange macro you can never use because something else might be relying on it. Just like you shouldn't be overriding %_fixperms for your use because it breaks other things. The idea of a pre/post action slots for macros and whatnot is not a bad one as such, but it'd need a different mechanism. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2961#issuecomment-2033745504 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 ability to specify extra command after %setup (PR #2961)
Closed #2961. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2961#event-12336249093 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 support for setting the build time and clamping to the build time (PR #2944)
@pmatilai commented on this pull request.
> @@ -240,10 +240,12 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%use_source_date_epoch_as_buildtime 0
-# If true, make sure that timestamps in built rpms
-# are not later than the value of SOURCE_DATE_EPOCH.
-# Is ignored when SOURCE_DATE_EPOCH is not set.
-%clamp_mtime_to_source_date_epoch 0
+# Defines file timestamp handling in built rpms. Possible values
+# are "clamp_to_buildtime" and "clamp_to_source_date_epoch",
+# which makes sure the the file timestamps are not later than
+# the build time of the package or the value of
+# SOURCE_DATE_EPOCH, respectively.
+#%build_mtime_policy
This new stuff should also be documented in docs/manual/buildprocess.md
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944#pullrequestreview-1975739792
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 support for setting the build time and clamping to the build time (PR #2944)
@pmatilai commented on this pull request.
>
-/* Limit the maximum date to SOURCE_DATE_EPOCH if defined
- * similar to the tar --clamp-mtime option
- * https://reproducible-builds.org/specs/source-date-epoch/
- */
-if (srcdate && rpmExpandNumeric("%{?clamp_mtime_to_source_date_epoch}")) {
- char *endptr;
- errno = 0;
- source_date_epoch = strtol(srcdate, , 10);
- if (srcdate == endptr || *endptr || errno != 0) {
- rpmlog(RPMLOG_ERR, _("unable to parse %s=%s\n"),
"SOURCE_DATE_EPOCH", srcdate);
- fl->processingFailed = 1;
+/* backward compatibility */
+if (!*mtime_policy_str) {
+if (srcdate &&
rpmExpandNumeric("%{?clamp_mtime_to_source_date_epoch}")) {
Maybe this should issue a deprecation warning?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944#pullrequestreview-1975738512
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 --patches and --sources aliases to rpmspec (PR #3011)
Coming to the conclusion that it's just not worth the trouble right now. I'll revive this once we've fixed the order (filed a ticket for that) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3011#issuecomment-2033714434 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 --patches and --sources aliases to rpmspec (PR #3011)
Closed #3011. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3011#event-12336023902 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] Sources and patches in src.rpm are stored in reverse order (Issue #3014)
And, once we do, revive https://github.com/rpm-software-management/rpm/pull/3011 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3014#issuecomment-2033713203 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] Sources and patches in src.rpm are stored in reverse order (Issue #3014)
Sources and patches are stored in a singly linked list with front insertion in the spec parser, and this implementation detail leaks into packages and rpmspec queries: PATCH and SOURCE tags are in reverse order. Technically changing the order *could* break somebody's carefully crafted script but few people even know they *can* retrieve the patches and sources from a header/rpmspec query. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3014 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 --patches and --sources aliases to rpmspec (PR #3011)
The thought crossed my mind too, I'm a bit torn on this all. Sure, reverting the order in the aliases would be safe. But, it seems like a bug that we're storing them in reverse order in the package in the first place, and something we should fix instead. But, that'd break it for the alleged existing users who are reverting it. Are there any? I really don't know, because few people even know you can query the patches like that. The more I think about it, the less likely it seems that doing the right thing and reverting the order of sources and patches would break anything. Had people run into that order reversion, I would've probably heard of it. And this is actually the first time that even I so much as notice it :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3011#issuecomment-2033675076 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] Create content handler plugin hook (PR #2416)
Apologies for this not progressing anywhere, but the time in between has confirmed that something like this will need a general purpose use-case in rpm itself so that it can be regularly tested. We'll be exploring this area in the future, but this isn't the time, we need to focus on v6. I'm closing this now because it doesn't do anybody any good to have old PR's hanging around. I've backed up your patch for possible future use/reference. Thanks for your work on this! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2416#issuecomment-2033653423 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] Create content handler plugin hook (PR #2416)
Closed #2416. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2416#event-12335589169 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 FA_REFLINK file action (PR #2557)
Apologies for this not progressing anywhere, but the time in between has confirmed that something like this will need a general purpose use-case in rpm itself so that it can be regularly tested. We'll be exploring this area in the future, but this isn't the time, we need to focus on v6. I'm closing this now because it doesn't do anybody any good to have old PR's hanging around. I've backed up your patch for possible future use/reference. Thanks for your work on this! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2557#issuecomment-2033653268 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 FA_REFLINK file action (PR #2557)
Closed #2557. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2557#event-12335587655 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 with Copy on Write (PR #3007)
I thought I made it pretty damn clear in https://github.com/rpm-software-management/rpm/pull/2378#issuecomment-1411912184: this is not functionality that we want to see or maintain in rpm. Period. Copy-on-write is an interesting technology in itself and we'll be exploring that in the future, but this "transcoding on the fly" business is insecure and not fit for general purpose use. And that's why it's be poor use of your resources to support this case. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3007#issuecomment-2033641542 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 with Copy on Write (PR #3007)
Closed #3007. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3007#event-12335494693 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] Implement a way to ensure build artifacts integrity after the `%build`, and during post-build phases like `%check` (Discussion #3009)
That mock does something is not a reason to not improve rpmbuild security and package/packaging sanity enforcement. A test-suite modifying what gets packaged is simply *horribly wrong*, even if it's by accident. If we can catch that, then we should. That's a no-brainer to me. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3009#discussioncomment-8992586 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
