Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild: make it possible to not include SPEC tag (rpm-4.17 compat behavior) (Issue #2727)
Sorry but no, as we've already said several times in several places. Not for this reason anyhow. We want to be able to rely on this tag being there in packages built with a modern rpm. And that is what the suggested change breaks. When you build it in a container of the "target era", it's built by an older rpm which obviously cannot be expected to put a tag it doesn't know about in there. This is business as usual. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2727#issuecomment-1980224382 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] Raise an error when passing arguments to non-parametric macros (PR #2940)
%{zzz foo} handled now, totally forgot that one...
I do think it should be an error just like it is on builtins, but noticed that
in the ticket this is something you stumbled on in the wild, so we can make it
a warning for a while and later turn it into an error. So, warning it is for
now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2940#issuecomment-1980211423
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] How to obsolete package once their dependencies are not satisfied? (Discussion #2938)
Yeah this is something for the depsolve layer, rpm has no concept of repos and cannot know what packages are available. On the depsolve layer this becomes a somewhat different problem: is the package really gone, or is it just temporarily unavailable due to out of sync mirrors or another repo issue? So probably not on by default, but system-upgrade should have it enabled. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8689178 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)
@pmatilai commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf ", spec->buildDir, "\n",
Fixed now, and thanks for the reminder. Had totally forgotten it...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#discussion_r1513878202
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)
@pmatilai commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf ", spec->buildDir, "\n",
Aagh :laughing:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#discussion_r1513873702
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 %dirname behave like dirname (3) (PR #2945)
Maybe the basename() case should also have some more advanced tests than the one that is there to match the added dirname cases, see @mlschroe's link. Other than that, looks fine now. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2945#issuecomment-1978878028 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 %dirname behave like dirname (3) (PR #2945)
@pmatilai commented on this pull request.
> @@ -1306,9 +1307,9 @@ static void doFoo(rpmMacroBuf mb, rpmMacroEntry me,
> ARGV_t argv, size_t *parsed)
b++;
} else if (rstreq("dirname", me->name)) {
buf = xstrdup(argv[1]);
- if ((b = strrchr(buf, '/')) != NULL)
- *b = '\0';
- b = buf;
+ b = xstrdup(dirname(buf));
They are indeed, and then there's glibc version of basename() which differs in
that it takes a const char * argument and relying on that is incompatible and
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2945#discussion_r1512893192
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] CMakeLists.txt: eliminate floating dependencies (PR #2914)
Yeah, while the patch here just mirrors what we already do, it does feel a bit draconian. The autotools-era standard was to autodiscover unless overridden one way or the other, when moving to cmake I just took the shortest shortcut I could find: make most stuff mandatory, allow disabling. OTOH I don't think there were any switches for the IO stuff even in autotools, which is why those options were not replicated to cmake. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2914#issuecomment-1978822827 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 %dirname behave like dirname (3) (PR #2945)
@pmatilai commented on this pull request.
> + if (!strcmp(buf, "")) {
+ buf = rstrcat(, ".");
+ } else if (strcmp(buf, ".") && strcmp(buf, "..") && strcmp(buf, "/")) {
+ /* strip trailing / */
+ size_t l = strlen(buf);
+ if (buf[l-1] == '/')
+ buf[l-1] = '\0';
+ if ((b = strrchr(buf, '/')) != NULL)
+ if (b == buf)
+ /* keep root dir */
+ buf[1] = '\0';
+ else
+ *b = '\0';
+ else
+ strcpy(buf, ".");
+ }
It's a good question. You have to go pretty far back (commit
94f5fbeec363059ca9eb986ee294ffcdf20bcb04) and come back none the wiser :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2945#discussion_r1512774126
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 %dirname behave like dirname (3) (PR #2945)
@pmatilai commented on this pull request.
> @@ -1306,9 +1307,9 @@ static void doFoo(rpmMacroBuf mb, rpmMacroEntry me,
> ARGV_t argv, size_t *parsed)
b++;
} else if (rstreq("dirname", me->name)) {
buf = xstrdup(argv[1]);
- if ((b = strrchr(buf, '/')) != NULL)
- *b = '\0';
- b = buf;
+ b = xstrdup(dirname(buf));
There's no need to xstrdup() twice here.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2945#pullrequestreview-1916802669
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 %dirname behave like dirname (3) (PR #2945)
Right, I don't know why these aren't calling the respective stdlib functions to begin with. It's not like it's expensive or anything. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2945#issuecomment-1978694251 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] %{dirname:foo} is returning foo (Issue #2928)
Indeed, there's no deeper meaning to the test, it's all about argument handling and nothing to do with dirname itself (the context of c5909bd8698e56ffa4d1bb380116d61d6b48b8dd makes it quite clear) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2928#issuecomment-1978679458 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] Weak dependencies do not allow qualifiers (#624)
Reopened #624. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/624#event-12012718668 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] Weak dependencies do not allow qualifiers (#624)
Reopening, this never actually worked or it has regressed: > $ rpmbuild -bb simple.spec error: line 8: Unknown tag: Recommends(meta): fu -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/624#issuecomment-1978585547 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 %dirname behave like dirname (3) (PR #2945)
@pmatilai commented on this pull request.
> + if (!strcmp(buf, "")) {
+ buf = rstrcat(, ".");
+ } else if (strcmp(buf, ".") && strcmp(buf, "..") && strcmp(buf, "/")) {
+ /* strip trailing / */
+ size_t l = strlen(buf);
+ if (buf[l-1] == '/')
+ buf[l-1] = '\0';
+ if ((b = strrchr(buf, '/')) != NULL)
+ if (b == buf)
+ /* keep root dir */
+ buf[1] = '\0';
+ else
+ *b = '\0';
+ else
+ strcpy(buf, ".");
+ }
Um, why not call dirname() instead?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2945#pullrequestreview-1916571693
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] --deploops doesn't report loops for erased packages (Issue #2946)
For example, `rpm -e --test --deploops fwupd fwupd-plugin-modem-manager fwupd-plugin-uefi-capsule-data fwupd-plugin-flashrom` on Fedora 39 shows no output despite there being a dependency loop that causes an incorrect erase order. On install it's visible: > warning: 1 Strongly Connected Components warning: SCC #1: 4 members (0 external dependencies) warning:fwupd-1.9.5-2.fc39.x86_64 warning:-> fwupd-plugin-uefi-capsule-data-1.9.5-2.fc39.x86_64 warning:-> fwupd-plugin-modem-manager-1.9.5-2.fc39.x86_64 warning:-> fwupd-plugin-flashrom-1.9.5-2.fc39.x86_64 warning:fwupd-plugin-modem-manager-1.9.5-2.fc39.x86_64 warning:-> fwupd-1.9.5-2.fc39.x86_64 warning:fwupd-plugin-uefi-capsule-data-1.9.5-2.fc39.x86_64 warning:-> fwupd-1.9.5-2.fc39.x86_64 warning:fwupd-plugin-flashrom-1.9.5-2.fc39.x86_64 warning:-> fwupd-1.9.5-2.fc39.x86_64 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2946 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 (Discussion #2934)
In case folks didn't notice the PR from @mlschroe : https://github.com/rpm-software-management/rpm/pull/2944 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8676851 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.
> @@ -245,6 +245,10 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%clamp_mtime_to_source_date_epoch 0
+# If true, make sure that timestamps in built rpms
+# are not later than the build time of the package.
+%clamp_mtime_to_buildtime 0
This means we now have two independent knobs for the same thing, and both
cannot be right.
I'd rather have something like `%clamp_mtime` macro that accepts
none/buildtime/source_date_epoch as possible values.
`%clamp_mtime_to_source_date_epoch` can then be deprecated and routed to the
new macro for now, for backwards compatibility.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944#pullrequestreview-1916204585
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)
@pmatilai commented on this pull request.
> @@ -1060,71 +1069,72 @@ typedef const struct PreambleRec_s {
int type;
int deprecated;
int ismacro;
+int beforebuildonly;
This is certainly better than the not-version (negations in variable names are
the wrong thing, every time), just looks somehow out of place in that company.
"prebuild" maybe? Not that this name is a hill to die for :laughing:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2917#pullrequestreview-1916104539
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)
Thirteenth time the charm, eh? :smile: Should be fixed up now, and thanks guys for spotting this stuff. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1978136786 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)
@pmatilai commented on this pull request.
> if (initialPackage) {
if (checkForRequiredForBuild(pkg->header)) {
goto exit;
}
- char *buildRoot = rpmGetPath(spec->buildRoot, NULL);
- free(spec->buildRoot);
- spec->buildRoot = buildRoot;
- rpmPushMacro(spec->macros, "buildroot", NULL, spec->buildRoot,
RMIL_SPEC);
- if (*buildRoot == '\0') {
- rpmlog(RPMLOG_ERR, _("%%{buildroot} couldn't be empty\n"));
- goto exit;
+ /* Grab the top builddir on first entry as we'll override _builddir */
+ if (!rpmMacroIsDefined(spec->macros, "_top_builddir")) {
+ rpmPushMacro(spec->macros, "_top_builddir", NULL, "%{_builddir}",
Oh indeed. The logic for setting %builddir does work, but %_top_builddir will
end up pointing to %builddir instead which is not the intention.
I'll fixup and make all these macros use RPMMACRO_LITERAL, that's the right
thing here really.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#discussion_r1512242474
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)
So... I would think that this is ready now, for real :sweat_smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1976610890 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)
Renamed the builddir creation script to %mkbuilddir (along with the enum) in the last push to disambiguate the two. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1976609669 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)
@pmatilai pushed 1 commit. fbf6913aef6b851b75f17feb7ea108e1d8143404 Introduce an rpm-controlled per-build directory -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885/files/c661ba05dd7d9b745f84df7f6123c270f7160bd6..fbf6913aef6b851b75f17feb7ea108e1d8143404 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)
@pmatilai pushed 1 commit. c661ba05dd7d9b745f84df7f6123c270f7160bd6 Introduce an rpm-controlled per-build directory -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885/files/9fb0bd8ac2899d6f0cd5e9c05280fbb3a544bf17..c661ba05dd7d9b745f84df7f6123c270f7160bd6 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)
Ended up renaming %pkgbuilddir to %builddir as per your and my gut feelings - we don't have "pkg" anywhere at all in our macros so introducing it here would seem a bit strange somehow. Updated the docs a bit + added couple of tests to demonstrate the new layout and behavior. As a side-note, SPECPARTS behaves a little funny here because it's only created from %setup (because there was no other place to do it before), but could be moved to %builddir script. Ehh, that made me notice there's an ambiguity in the naming now: the script and the directory that the script creates are both called %builddir. Maybe the script needs to be called %mkbuilddir instead. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1976549673 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)
@pmatilai pushed 2 commits. a162fe61525ff91768299a7231e8ca3d4cf25ce3 Print informative messages to stderr, not stdout on --target build 9fb0bd8ac2899d6f0cd5e9c05280fbb3a544bf17 Introduce an rpm-controlled per-build directory -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885/files/b6cf728569212192543f768b475a2ad9fef47460..9fb0bd8ac2899d6f0cd5e9c05280fbb3a544bf17 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] build: reword "%changelog is missing" (PR #2943)
Merged #2943 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2943#event-11994555634 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] build: reword "%changelog is missing" (PR #2943)
Oh right, a %changelog with no entries is an anomaly I remember running into in the past, possibly rpm 4.6.x days. The new message does make it much clearer what the deal is, thanks. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2943#issuecomment-1975910983 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)
Merged #2933 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2933#event-11994537731 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)
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: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1975908070 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)
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 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)
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: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1975904107 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 customizable default of RPMBUILD_RMBUILD in rpmbuild (--noclean) (Discussion #2942)
rpmbuild -bi does run %check, and it also runs the usual files checks. Like I said, it basically does everything but produce binaries. `fedpkg install` (it's a weird name for what it does, yes) is the fedpkg equivalent. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2942#discussioncomment-8643366 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 customizable default of RPMBUILD_RMBUILD in rpmbuild (--noclean) (Discussion #2942)
If you don't care about binaries then why are you building them in the first place? 'rpmbuild -bi' and will do all the same build steps, only it wont procuce packages or clean the build, because it's *intended* for that sort of work. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2942#discussioncomment-8643293 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: Issue dependency loop warnings by default (Issue #2941)
As distros keep growing and getting more complex, there's an ever increasing amount of dependency loops causing install failures without us giving any meaningful hints at what could be wrong. Rpm has "always" had a --deploops switch that can be enabled for diagnosing loops, but we should really emit that output by default. Small loops can usually be handled without problems so we probably shouldn't emit warnings on every single loop, but instead issue warnings over a configurable threshold. Based on what I've seen over the years, a loop with >= 100 members has no chance of getting correctly installed, whereas a loop with <= 10 are rarely problematic. The default threshold should be somewhere between those two... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2941 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)
Good point on the docs, that dynamic stuff certainly needs updating, but there could be other things too. Like, explaining the new layout somehow. Not that packagers *need* to know but it doesn't exactly hurt either. It's possible this could use a test or two as well... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1970971120 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)
> Update 2: Is there an actual need for a SPEC to ever use the %pkgbuilddir (or
> %builddir for that matter) macro? If not, why not make it at least "private"
> with an underscore?
Oh, I actually mulled about %builddir without the underscore as the
user-oriented name for this. I too kinda liked that more, I think I ended up
with the pkg-version to make minimize confusion with %_builddir. OTOH, like you
said we already have %buildroot and %builddir would seem more consistent with
that. I could quite easily be convinced either way :smile:
> Update 3: Oh... you actually mentioned that "a LOT of packages reference
> %_builddir for all sorts of (mostly bad) reasons" in the commit message. In
> that case, why introduce yet another such macro at all?
Primarily because %_builddir is ambiguous, you don't really know whether it's
the bad old or good new. It still points to the potentially shared
%{_topdir}/BUILD by default, whereas %pkgbuilddir (or %builddir) is only
defined during the actual build (which is also the only time that directory
exists).
Note that the "mostly bad" stops being bad with this change - this is now the
legit place for packages to use for their needs during the build.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1970968229
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)
@pmatilai commented on this pull request.
> {0, 0, 0, 0}
};
/**
*/
static int findPreambleTag(rpmSpec spec,rpmTagVal * tag,
- const char ** macro, char * lang)
+ const char ** macro, char * lang, int * beforebuildonly)
findPreambleTag() is of course pre-existing code that just gets extended here
so this is just a side-remark, but this function sure looks like it'd be much
saner to just return a pointer to the struct instead of all these separate
return pointers.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2917#pullrequestreview-1908639748
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)
@pmatilai commented on this pull request.
> + return p->token;
+ }
+}
+return NULL;
+}
+
+static const int partBeforeBuildOnly(int part)
+{
+const struct PartRec *p;
+
+for (p = partList; p->token != NULL; p++) {
+ if (p->part == part) {
+ return p->beforebuildonly;
+ }
+}
+return 0;
I'd combine these two into findPart() that returns a pointer to the struct,
whose values you can then just use directly in the caller.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2917#pullrequestreview-1908632646
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] 4.19.1.1: `rpmbuild --undefine foo` is not working (Discussion #2939)
Closed #2939 as resolved. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2939 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] 4.19.1.1: `rpmbuild --undefine foo` is not working (Discussion #2939)
No, it doesn't. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2939#discussioncomment-8618040 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 (Discussion #2934)
Oh BTW, just a quick side-remark on this: > OPTFLAGS and PLATFORM are often different because a "random" noarch package > is selected OPTFLAGS shouldn't be even defined on noarch builds, much less included in the header. The former is hard to fix for various hysterical reasons, but the latter should be easy. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8618013 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 (Discussion #2934)
> I saw "reproducability" mentioned a few times. I assume it's not a typo, but > I have no idea how it's supposed to be different from "reproducibility". Eh. All my life I've been talking about reproducers, and reproducable bugs. And now builds. :flushed: That misspelling is going to be hard to unlearn, but thanks for setting me straight there. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8617916 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] 4.19.1.1: `rpmbuild --undefine foo` is not working (Discussion #2939)
No, read what I wrote more carefully. Neither --define or --undefine can affect a macro *defined inside a spec*. Both can affect the parse, and cause things to be defined or undefined, but only wrt macros that are defined before the macro is parsed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2939#discussioncomment-8617830 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] Raise an error when passing arguments to non-parametric macros (PR #2940)
@mlschroe I know you closed the ticket already but this seems like the right thing to do... Or does this actually break some odd case that I'm not aware of? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2940#issuecomment-1968873107 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] Raise an error when passing arguments to non-parametric macros (PR #2940)
Fixes: #2932 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2940 -- Commit Summary -- * Raise an error when passing arguments to non-parametric macros -- File Changes -- M rpmio/macro.c (5) M tests/rpmmacro.at (14) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2940.patch https://github.com/rpm-software-management/rpm/pull/2940.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2940 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Incorrect examples in the embedded lua documentation (Issue #2929)
Oops. Thanks for reporting! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2929#issuecomment-1968842291 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] Incorrect examples in the embedded lua documentation (Issue #2929)
Closed #2929 as completed via ebece0fb63f7e68801b5c696a45a9957db5dcfa1. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2929#event-11950741697 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] 4.19.1.1: `rpmbuild --undefine foo` is not working (Issue #2923)
@pmatilai converted this issue into discussion #2939. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2923#event-11950668138 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] 4.19.1.1: `rpmbuild --undefine foo` is not working (Issue #2923)
--define and --undefine execute long before the spec is parsed, so while they can affect the way a spec is parsed, neither can affect a macro defined inside a spec. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2923#issuecomment-1968830695 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] 4.19.1.1: `rpmbuild --undefine foo` is not working (Issue #2923)
Closed #2923. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2923#event-11950665504 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)
@pmatilai commented on this pull request.
> @@ -1060,71 +1069,72 @@ typedef const struct PreambleRec_s {
int type;
int deprecated;
int ismacro;
+int notgenerated;
"notgenerated" is not the greatest name ever :smile:
Maybe "isgenerated" and just flip the meaning around? Other possibilities could
be something around dynamic/static.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2917#pullrequestreview-1905882276
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)
@pmatilai commented on this pull request.
> @@ -1109,6 +1123,25 @@ static rpmRC parseSpecSection(rpmSpec *specptr, int
> secondary)
goto errxit;
}
+ if (stage == PARSE_GENERATED) {
+ switch (parsePart) {
+ case PART_PREP:
+ case PART_BUILD:
+ case PART_INSTALL:
+ case PART_CHECK:
+ case PART_CLEAN: /* */
+ case PART_BUILDARCHITECTURES:
+ case PART_PATCHLIST:
+ case PART_SOURCELIST:
+ case PART_BUILDREQUIRES:
+ case PART_CONF:
Not sure if this was in the earlier version or I just missed it, but this info
should go to struct PartRec for the same reason as the tags: to force people to
consider the matter when adding new.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2917#pullrequestreview-1905879453
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)
Merged #2921 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2921#event-11949396433 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)
@pmatilai approved this pull request. Looks fine now, thanks. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2921#pullrequestreview-1905848211 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] Check packages for consistency when opening them (Issue #2937)
This would actually be more like a long-term project than an individual ticket you can just fix, because it's just enormous. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2937#issuecomment-1968508933 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)
> 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] 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] 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-software-management/rpm/pull/2...@github.com ___ 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] 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
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] 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
Re: [Rpm-maint] [rpm-software-management/rpm] Add --list-keys and --delete-key to rpmkeys (PR #2921)
@pmatilai 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);
Again, why the macro expand? 'rpmkeys --delete %{somemacro}' seems like a weird
use-case to support, I'd think for something like OpenPGP keys you'd rather
always be explicit about the key.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2921#pullrequestreview-1902735001
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)
@pmatilai 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();
argvNew() is wholly unnecessary here (it almost always is), just initialize to
NULl and argvAdd() and similar will alloc it as needed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2921#pullrequestreview-1902726014
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)
Closed #2931. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2931#event-11931992514 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)
Gone in 217e217d92ec660f42ad8bfe979503d3ab556a54 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2931#issuecomment-1965941397 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)
Oh. Actually, that whole sentence is wrong/misleading, rpm2cpio requires a functional librpm just as much as rpm2archive does. I'll just delete it, but thanks for pointing this out! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2931#issuecomment-1965930678 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 (Discussion #2924)
No, because I had no idea. I don't particularly follow sqlite developments because there aren't any active developments or plans in that direction. But clearly we need to do something about it sooner or later then, filed https://github.com/rpm-software-management/rpm/issues/2925 so it gets tracked. Thanks for the heads-up! :+1: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2924#discussioncomment-8554720 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] RPM uses pragma case_sensitive_like which is deprecated from sqlite 3.44 (Issue #2925)
### Discussed in https://github.com/rpm-software-management/rpm/discussions/2924 Originally posted by **vbrahmajosyula1** February 22, 2024 sqlite 3 deprecates pragma_case_sensitive_like from 3.44 https://www.sqlite.org/changes.html. Following patch introduced case_sensitive_like in RPM. https://github.com/rpm-software-management/rpm/commit/bea298986d796900dd94de42dec98fb194df1ff8 Seems we need to do something about it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2925 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)
Eliminating any ideas of shared build/buildroot content and associated shenanigans (and consequent problems) is one of the *goals* of this PR. Utopistic-ideally, a build would not have access to any content outside this dedicated build directory. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1958913966 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)
> Well, I stuck to the names that were in the code... I know. My not-so-thoroughly thought up names from 10+ years ago, and a fine example of why not to leave such half-assed pieces laying around in the codebase :laughing: > It also uses "--delete" while rpm itself uses "--erase". Not sure if that is > good because it is a slightly different operation or bad because it is > inconsistent. Opinions? I'm quite sure I chose the names for familiarity from gpg, which has --list-keys and --delete-keys. I always quite disliked the "erase" terminology in rpm anyhow. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2921#issuecomment-1958879565 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 v6 package format draft, major update (Discussion #2919)
Heh, I didn't remember the workaround for 3.x, that's pretty funny. That would've been added by a rather green me, probably in 2007 or so, thinking this checking is a good thing. And then nobody thought to update the name when the new payload format was added years later. It's annoying how much that little slip some ten years ago is hurting just now. It's something to consider. While v6 always uses the new non-cpio payload, the community has shown interest in other types of payload too, and having a clean mechanism for this would of course be nice. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8553156 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 v6 package generation rough-cut (PR #2920)
@pmatilai commented on this pull request.
> headerDel(pkg->header, RPMTAG_PAYLOADDIGEST);
headerPutString(pkg->header, RPMTAG_PAYLOADDIGEST, pld);
headerDel(pkg->header, RPMTAG_PAYLOADDIGESTALT);
headerPutString(pkg->header, RPMTAG_PAYLOADDIGESTALT, upld);
pld = _free(pld);
+if (pkg->rpmver >= 6) {
+ headerDel(pkg->header, RPMTAG_PAYLOADSIZE);
+ headerPutUint64(pkg->header, RPMTAG_PAYLOADSIZE, , 1);
+ headerDel(pkg->header, RPMTAG_PAYLOADSIZEALT);
+ headerPutUint64(pkg->header, RPMTAG_PAYLOADSIZEALT, , 1);
All the archive size related tags are in the signature header in v4, they're
just translated and appended (as dribbles) to the main header upon package
read. The reason for entirely new tags is that this is ALWAYS in the main
header and thus hashed, whereas all the v4 archive size tags are always
non-hashed. There's maybe no strict "we absolutely need this" use for the size,
BUT since the info is easily available and is now reliable, I don't see why
not. There are more useless bits of data in the header :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2920#discussion_r1498778226
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 v6 package format draft, major update (Discussion #2919)
Oh, RPMSIGTAG_FILESIGNATURELENGTH needs to be dropped because it's just broken. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8543365 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] Don't install README.md from docs/ (Issue #2811)
Closed #2811 as completed via 126b7ab7af60f79fe1912dec19c865f2ea74965a. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2811#event-11874943984 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)
I wont claim to have digested all that, but just a high level confirmation: what I really would like to see is a coherent (re)design for reproducible builds, where you basically just flick it on and be done with it, whereas the existing flags reflect the organic growth process over the years and still much of the assembly is left to the user. And, to me it's not a big deal if its incompatible to older releases because this is something you set at a buildsystem level rather than per-spec thing. Such a change could of course only go into a new major release and not for backporting. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2894#issuecomment-1956424107 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] %missingok is undocumented (Issue #2833)
Closed #2833 as completed via b2638067fce9a32cba03f5c0198ea50a33ff6d3d. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2833#event-11874285931 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] Safer handling of internal soname dependencies (Issue #2922)
### Discussed in https://github.com/rpm-software-management/rpm/discussions/2872
Originally posted by **pmatilai** January 24, 2024
This is one of those topics that gets raised semi-annually at least. To point
out a couple, https://bugzilla.redhat.com/show_bug.cgi?id=2259260 and
https://bugzilla.redhat.com/show_bug.cgi?id=1464368 and
https://github.com/rpm-software-management/rpm/issues/1227 but there are
certainly more out there.
For some cases like an unfortunately named project starting with lib having a
Python/Perl module, the provide may be mostly harmless if ugly. The far worse
issue is bundled libraries that are incompatible with the system ones and not
even in the path, but create identical provide names which a depsolver may end
up pulling instead of the system level library, and break things quite badly.
The fundamental issue may well be unsolvable, the main focus here is to look
for a solution that makes those bundled libraries less dangerous. If other
problems get solved while we're at it, great.
The common suggestion is to filter out soname dependencies outside the system
library path, but this has multiple problems: filtering them on the rpm
metadata level doesn't make the dependencies go away, and they may well be
needed for sub-packages and so on. What may work better is transforming the
sonames dependencies for libraries outside system path to something else,
perhaps including the parent package name in the name so it can't be mixed with
the system or somebody elses bundled library. For provides one can do this by
parsing /etc/ld.so.conf[.d] but requires seems to require solving, which is
something elfdeps doesn't (and IMO, shouldn't) do. (I don't like parsing other
people's config files either, but that seems unavoidable)
One simple possibility would be giving elfdeps a list/regex of soname prefixes
to match. Eg, passing "libxml2" would cause it to map any dependencies found on
libxml* to some other, internal-suggesting name. Such as %{name}-libxml*. That
list/regex could be set by the packager, but to satisfy the goal of bundled
library safety, it needs to happen automatically for provides. I guess
something like this would do:
1. figure out system library path, considering ld.so.conf[.d] in the buildroot
and everything
2. find out any shared libraries in the buildroot outside that path
3. set the elfdeps mangler (eg %{name}-) to apply to everything
found in 2
4. profit?
Mangling discovered dependencies isn't hard, retrofitting the discovery parts
to the rpm framerwork probably is.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2922
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)
> With our build system, passing constants into a build is much easier than > passing in a variable %_buildtime. Sorry but I have no idea this means. What are these "constants" and how are they being passed to a build? (a %_buildtime macro could be set either via rpmbuild command line --define or a macro file such as ~/.rpmmacros) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2894#issuecomment-1956156213 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)
@pmatilai commented on this pull request.
> case MODE_LISTKEY:
+ if (args != NULL) {
+ argerror(_("--list-keys does not take any arguments"));
+ }
+ ARGV_t query = argvSplitString("gpg-pubkey", " ", ARGV_NONE);
It's a bit creative way to initialize an argv... I think
```
ARGV_t query = NULL;
argvAdd(, "gpg-pubkey");
```
...would be a well worth the one extra line in obviousness :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2921#pullrequestreview-1892397084
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)
@pmatilai commented on this pull request.
> case MODE_LISTKEY:
+ if (args != NULL) {
+ argerror(_("--list-keys does not take any arguments"));
I think it should (take optional arguments), actually. It could be useful for
eg checking whether a particular key is imported, without having to query all
and grep.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2921#pullrequestreview-1892392916
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: allow append to previously declared spec sections (#1240)
Hum, forgotten to close this. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1240#issuecomment-1956106945 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: allow append to previously declared spec sections (#1240)
Closed #1240 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1240#event-11872482217 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] Provide a decent API for verifying package signatures (Issue #2041)
I don't see this happening in 4.20, dropping from the milestone. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1956097606 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)
I think I initially wanted to add a sane API for these and then have rpmkeys use that, and when that seemed painful I gave up. But the user wont care *how* it's achieved if it works in a meaningful manner. And, for the user this is far saner than 'rpmkeys --import -> rpm -q -> rpm --erase'. Two things: 1) Lets make the option names consistent - either they all should have plural -keys, or none should have it. Since the pre-existing --import doesn't have it, maybe the --delete and --list shouldn't have either? Or, we could add --import-keys as alias to --import. 2) Tests for both added operations. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2921#issuecomment-1956077388 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)
@pmatilai commented on this pull request. > @@ -75,7 +74,29 @@ int main(int argc, char *argv[]) break; /* XXX TODO: actually implement these... */ Maybe delete this comment while at it? :smile: A fine example of why comments are so bad - they don't get updated along with the code. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2921#pullrequestreview-1892306320 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)
@pmatilai commented on this pull request.
> @@ -75,7 +74,29 @@ int main(int argc, char *argv[])
break;
/* XXX TODO: actually implement these... */
case MODE_DELKEY:
+ struct rpmInstallArguments_s * ia =
+ ARGV_t gpgargs = argvNew();
+ for (char * const * arg = args; *arg; arg++) {
+ if (strncmp(*arg, "gpg-pubkey-", 11)) {
+ char * gpgarg = rpmExpand("gpg-pubkey-", *arg, NULL);
Why the macro expand? That seems weird/wrong in this context.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2921#pullrequestreview-1892305237
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)
Forward-looking defaults aside... Do you agree with the idea that there should be a single macro to set the buildtime source (clock/macro/source_date_epoch), and then have a separate flag for clamping mtimes to buildtime, or am I again missing some finer detail here? I've nothing against reproducible builds, it's this tangle of haphazard switches that annoys me. Tagging in folks who I remember showing interest in reproducible builds in the past, feel free to include more if/when I missed someone: @JanZerebecki @Conan-Kudo @bmwiedemann @boklm -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2894#issuecomment-1956052423 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
