Re: [Rpm-maint] [rpm-software-management/rpm] Improve the debuginfo enablement backwards compatibility (PR #3098)
Merged #3098 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3098#event-12800386736 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] Dynamic generator generates "invalid" srpm (Issue #3096)
Summary is a mandatory field on rpm packages, we cannot very well write illegal packages. If we don't have a meaningful value we need to stick *something* in it. That said, this is probably a bridge too far and seems easily avoided by requiring the mandatory base tags to be supplied by the spec. They are not that many. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3096#issuecomment-2109839116 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 git-bisect in the test-suite in a friendly way (Issue #3097)
Yeah I'd prefer a place for ad-hoc tests, because whenever you need to bisect something you almost certainly want to add it to the test-suite afterwards. So if it's already in the test format, you just move it around without having to rewrite from some custom logic. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3097#issuecomment-2109587183 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 git-bisect in the test-suite in a friendly way (Issue #3097)
@pmatilai also suggested that we could have a slot in `rpmlocal.at` reserved for this that's never checked in. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3097#issuecomment-2109583813 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] Improve the debuginfo enablement backwards compatibility (PR #3098)
Move the enablement logic to %__spec_install_template where it can be buried with relatively little danger of being overridden by distros or packagers. It's moderately annoying as the logic isn't no longer neatly in one spot, but %__spec_install_post is commonly overridden by distros and even packages, and in particular we don't want to have packages copy-paste all this stuff along, because that makes making any changes to this stuff even harder than it already is. This should be entirely backwards compatible with all the pre-existing %__spec_install_post overrides. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3098 -- Commit Summary -- * Improve the debuginfo enablement backwards compatibility -- File Changes -- M platform.in (6) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3098.patch https://github.com/rpm-software-management/rpm/pull/3098.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3098 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] Support git-bisect in the test-suite in a friendly way (Issue #3097)
We could perhaps have a user-friendly way to do git-bisect with an ad-hoc test script that's not checked in to the repo, as suggested by @ffesti today. It seems like `make atshell` (or directly calling `./mktree atshell `) could be used for this. I'll need to give it a thought or two on one of these "hack on your favorite project" Fridays but it shouldn't be terribly difficult. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3097 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] Dynamic generator generates "invalid" srpm (Issue #3096)
I have used "valid" in a sense that I would not be allowed to create SRPM without e.g. summary. So apparently, this does not use the same code paths which is concerning. Also, when I saw the test case in https://github.com/rpm-software-management/rpm/commit/5d288554719095d1c67fd87cad65224743152d06, I though that would allow to have different preamble between SRPM / RPM, which would be nice (see #3046). But if that is not the case, I would rather if the possibility to generate the main package preamble was dropped, because otherwise it provides confusing results. And TBH, the test case with defining some macro is very artificial. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3096#issuecomment-2109476389 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] Free old cookie value to prevent a memory leak (PR #3095)
Merged #3095 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3095#event-12797198526 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] Free old cookie value to prevent a memory leak (PR #3095)
AIUI the cookie is intended to link packages from a single build together, and apparently I even documented that: "An opaque value for tracking packages from a single build operation" So this seems the right thing to do there, not that I know anybody using the cookie for anything... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3095#issuecomment-2109456672 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
