Re: [Rpm-maint] [rpm-software-management/rpm] Always create %specpartsdir on build (PR #3084)
This should still get it created in `%prep`, right? It _seems_ like that's the case. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3084#issuecomment-2106394010 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] Always create %specpartsdir on build (PR #3084)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3084#pullrequestreview-2051465619 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 proper logic for debuginfo enablement (PR #3085)
@Conan-Kudo approved this pull request. This is a lot cleaner and I like this setup. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085#pullrequestreview-2051465542 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 spec generation depends on %setup (for no good reason) (Issue #3063)
So this is similar to #3042 (and probably really just a more generic version of that issue). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3063#issuecomment-2092561549 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] Drop architecture from %builddir path (PR #3069)
Oh hey, thanks for that! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3069#issuecomment-2089251801 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] Automatically reload rpm configuration on mismatching BuildArch (PR #3071)
So what does this do when we use it to declare only a subpackage as noarch? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3071#issuecomment-2085451141 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] Convert a bunch of librpmio stuff to native C++ (PR #3054)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3054#pullrequestreview-2015563636 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] Return to Tralla La or: RPM in C++ (Discussion #2983)
Yeah, I've always been afraid of broaching the idea seriously. I had joked about this with @ffesti a few times at the openSUSE Conference, but I'm really glad to see us doing this. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-8982957 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)
@Conan-Kudo requested changes on this pull request. Actually, since these emit the sources and patches in reverse order, could we make the aliases also reverse that so they are in the correct order? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3011#pullrequestreview-1973492350 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)
Could you fix it for your rpmspec aliases though? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3008#discussioncomment-8982821 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)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3011#pullrequestreview-1973096004 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 bare `%package` (Discussion #2959)
So is the idea to be able to mimic the `debian/control` style of the top preamble actually being for the source package only, and then a bare `%package` section for the binary package of the same name? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2959#discussioncomment-8974431 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)
Yeah, it would be interesting for sure. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3009#discussioncomment-8974419 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] Return to Tralla La or: RPM in C++ (Discussion #2983)
For what it's worth, I'm excited about the transition to C++, because as a C++ programmer, I feel much more comfortable working my way through and cleaning things up leveraging the things I know well. So I'm looking forward to this! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-8953488 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)
This would be tremendously useful, especially for me trying to dig through really complex packages... Some of them are just not able to be intuited by reading, and being able to probe them like this would be really useful! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3008#discussioncomment-8945747 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 per-user macro configuration in XDG_CONFIG_HOME (PR #2992)
@Conan-Kudo requested changes on this pull request.
> +#ifdef MACROFILES
+static char *initMacroPath(const char *confdir)
+{
+return xstrdup(MACROFILES);
+}
+#else
+/*
+ * Prefer XDG_CONFIG_HOME/rpmmacros but fall back to ~/.rpmmacros
+ * if it exists and the XDG path doesn't.
+ */
+static char *initMacroPath(const char *confdir)
+{
+const char *xdgconf = getenv("XDG_CONFIG_HOME");
+if (!(xdgconf && *xdgconf))
+ xdgconf = "~/.config";
+char *dotpath = rpmGetPath(xdgconf, "/rpmmacros", NULL);
What about `$XDG_CONFIG_HOME/rpm/macros` instead? That mimics what we do in
`/etc/rpm` too.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2992#pullrequestreview-1958109674
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)
@Conan-Kudo 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
I will preface this that I think adding this knob is a seriously bad idea. But,
I think @pmatilai is right that _if_ we're going to do this, we should change
to a mode-setting macro like `%clamp_mtime` and have mode options.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944#discussion_r1528334316
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)
@Conan-Kudo commented on this pull request.
> - goto exit;
- }
- if (rstreq(buildRoot, "/")) {
- rpmlog(RPMLOG_ERR, _("%%{buildroot} can not be \"/\"\n"));
- goto exit;
+ if (!spec->buildDir) {
+ /* Grab top builddir on first entry as we'll override _builddir */
+ if (!rpmMacroIsDefined(spec->macros, "_top_builddir")) {
+ char *top_builddir = rpmExpand("%{_builddir}", NULL);
+ rpmPushMacroFlags(spec->macros, "_top_builddir", NULL,
+ top_builddir, RMIL_GLOBAL, RPMMACRO_LITERAL);
+ free(top_builddir);
+ }
+
+ /* Using release here causes a buildid no-recompute test to fail */
+ spec->buildDir =
rpmExpand("%{_top_builddir}/%{NAME}-%{VERSION}-%{_arch}", NULL);
Can we please not include architecture? That can leak into builds and cause
problems. That's why I had to make an adjustment in redhat-rpm-config for
`%_vpath_builddir`:
https://src.fedoraproject.org/rpms/redhat-rpm-config/c/e0cfcc0fc76a7642faabb25c5e348d6a1314ace2
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#pullrequestreview-1936534049
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)
I'd probably go with `RPMTAG_FILEMIME`. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8757616 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: multi-arch dependencies (Issue #2197)
> soft FP is a very rare thing these days, that's the exception that should be > encoded if at all - I know it's a thing you need to care about on Arm, at > least in the past, but is it something that needs to be in every single > dependency, really? We may need to care about it again with RISC-V. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2197#issuecomment-1985537895 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: store a copy of files maked as config in /usr/lib/rpm/config (#1178)
For a path, maybe this is where we finally introduce `/usr/lib/sysimage` as an expected path. I could see something like `/usr/lib/sysimage/rpm-config` be a valid location to store a whole hierarchy of pristine config files. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1178#issuecomment-1985520373 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)
@Conan-Kudo approved this pull request. Sure, I suppose. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2914#pullrequestreview-1916977215 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)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#pullrequestreview-1911698628 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)
Sounds good to me. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1973616134 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)
Oh, wouldn't we need these fixups for all the VCS backends, not just Git? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1973534254 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 don't think it's a good idea to offer. I am not convinced these knobs are a good idea for RPM to expose for any reason, especially reproducibility. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8643933 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 am aware of some tools that use `RPMTAG_BUILDTIME` to sort packages in various situations, especially if they have the same NVRA (ie. rebuilds). It is also useful in diagnostic purposes when trying to figure out a factor of breakage. I would rather not falsify this tag. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8643922 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)
> Before commit > https://github.com/rpm-software-management/rpm/commit/b34333fa021c0ee7215714eeef96d1a2843ea08e, > rpmbuild has by default kept built artifacts. RPM has deleted the buildroot tree by default since RPM 4.6. If it wasn't doing that before, that's a bug. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2942#discussioncomment-8643193 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've been bitten enough times personally that I would rather not have BUILDHOST and BUILDTIME set to fake values. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8630113 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)
You already need all the inputs to correctly reproduce packages in openSUSE. The build system doesn't capture this, but it's still required. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8618519 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)
It's also important to keep in mind the context of Debian style reproducibility: their archive format is a tarball with ar archives inside. That makes things very different for them than us. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8617949 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
Locking down the stored build time in the rpm headers to `SOURCE_DATE_EPOCH` can have other undesirable side-effects, so generally I wouldn't want that to be a thing for Fedora or any distribution, really. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1967579370 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Expose build time to package build scriptlets via $RPM_BUILD_TIME (PR #2933)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2933#pullrequestreview-1903336269 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
If we're not clamping the build-time but want the commits to be clamped (which is Fedora's configuration), then this is the way we need to do it. I do think that if SOURCE_DATE_EPOCH isn't set, we should clamp to RPM_BUILD_TIME though. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1966414614 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] support reproducible automatic rebuilds (PR #2880)
I don't think bumping the changelog for rebuilds is actually important, but I do think that this is still the wrong way to solve it, because we're presuming that _a rebuild is important_. When rebuilds happen every day for whatever reason due to dependency churn, they are no longer important. But that doesn't change anything about handling `$SOURCE_DATE_EPOCH`, because the presumption is that the date doesn't matter because you're fixing it to a fake time anyway. So this is solving the wrong problem anyway. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1966407685 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] support reproducible automatic rebuilds (PR #2880)
Since I was tagged in here and for some reason people think I don't care about reproducibility, let me be clear, I do care about it. However, neither Fedora nor openSUSE suffer from the problems Debian has that necessitated reproducible builds, and the nature of the RPM format vs the Debian format means that we do not have the same problems they do with build data influencing the payload reproducibility. Fedora has been so far ahead of Debian on this and the Koji build system provides guarantees (at the consequence of trade-offs like increased disk usage over time) that neither Debian's system nor OBS provide that there is less urgency around the issue. In general, rebuilds should not mutate or influence how reproducible builds behave. I'm confused by the problem you're saying you have: build-compare shouldn't have an issue with SOURCE_DATE_EPOCH being clamped to the changelog, since that's unchanging. The only issue I know if is that if you clamp the buildtime and don't change the Release, you wind up in a situation where it becomes difficult to sort for the newer package. Since OBS changes the Release for every rebuild, this isn't strictly an issue, but openSUSE should not be clamping the buildtime regardless. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1956556571 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)
Clamping the mtime to buildtime has its own negative consequence too, because it makes it harder to reason reproducibility and it invalidates reproducibility in practice because every build will be different due to a variable clamp rather than an immutable clamp. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2894#issuecomment-1956534803 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)
One of the reasons for the knobs is that not all of these settings are fully useful for "reproducibility" and some of these harm traceability and debugging. For example, forcing the build host to `reproducible` does not provide much value if you are able to do comparisons while stripping/ignoring specific RPM header values and makes it harder to determine when something weird is happening as a result of a build host in real-world debugging efforts. This is similarly true for clamping build times, and has the negative consequence of making it difficult for tools to sort packages when they were built with the same NVR. Setting `SOURCE_DATE_EPOCH` from the changelog provides value because it influences how the build itself records timestamps. Clamping mtimes provides value because it eliminates variability from the payload. Everything we do around "reproducible builds" needs to be viewed with the lens of handling this balance. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2894#issuecomment-1956531794 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)
> proper multiarch dependencies (instead of ()(64bit) markers) As a reminder, I took a stab at this in #360 and later #1038. The big change since then is the introduction of subarches for both ARM and x86_64, and I still expect that to happen for RISC-V too. What are we thinking for this now? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8529506 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)
We didn't even do this with the Autotools build scripts, I don't think we should make it so strict in the CMake build script either. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2914#issuecomment-1954138148 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] Including a file, expanding the macros in it and writing the result to another file? (Discussion #2912)
This should do the trick: ``` cat > expanded
Re: [Rpm-maint] [rpm-software-management/rpm] Adjust User/Group handling Documentation (PR #2903)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2903#pullrequestreview-1879061365 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)
FYI: @davide125 @michel-slm -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1918382019 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] support reproducible automatic rebuilds (PR #2880)
I will also point out that this is premised on some kind of "build counter" property that we don't have. @bookwar proposed [adding something like this to RPM and extending NVR to NVRB some time ago](https://discussion.fedoraproject.org/t/rfc-build-tag-in-rpms-nvr-nvrb/39954), but there has been no movement on that. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1918381531 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)
This seems to defeat the point. The point of this is to clamp the times to the date stamp in the changelog. If you're doing automatic rebuilds, you should not use that feature, full stop. You've effectively created a situation where your builds are not reproducible outside of your build system with the build system circumstances that created it. >From my reading of this, this is a very bad idea, and I'm not sure we should >have this. I also think that if this is something openSUSE is going to ship, >it should stop saying it's doing reproducible builds. (Yes, I'm aware of all the caveats of reproducible builds, please don't add more of them!) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2880#issuecomment-1918379446 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 user/group lookup caching thread-safe (PR #2843)
@Conan-Kudo approved this pull request. Modulo note as @dmnks stated, it looks good to me. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#pullrequestreview-1833116074 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 build directory auto path to setup step (PR #2859)
@Conan-Kudo requested changes on this pull request.
> @@ -17,6 +17,7 @@ target_link_libraries(rpmlua PRIVATE LUA::LUA)
target_link_libraries(rpmbuild PRIVATE librpmbuild)
target_link_libraries(rpmspec PRIVATE librpmbuild)
target_link_libraries(rpmdeps PRIVATE librpmbuild)
+target_link_libraries(rpmuncompress PRIVATE archive)
Is this the name of the dependency? It looks like it's `LIBARCHIVE` instead of
`archive`.
> @@ -509,6 +509,9 @@ can just create the directory. It accepts a number of
> options:
-n DIR set the name of build directory (default is `%{name}-%{version}`)
-T skip the default unpacking of the first source (used with
`-a` or `-b`)
+-p ensures that the sources will be in the default build directory,
How would this be exposed in `%autosetup`? We can't use `-p` there since that's
for patchlevel passed to `patch`. Maybe instead use `-C` and describe it as
`Create the build directory and ensure the archive contents are unpacked there,
stripping the top level directory in the archive if it exists`.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2859#pullrequestreview-1832404055
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 user/group lookup caching thread-safe (PR #2843)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#pullrequestreview-1821554619 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] Declarative buildsystem, take II (PR #2774)
Thanks for finally landing this! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1892038147 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] Declarative buildsystem, take II (PR #2774)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#pullrequestreview-1815228582 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 Issue templates for Bug reports and RFEs (PR #2823)
@Conan-Kudo commented on this pull request. > @@ -0,0 +1,22 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: RFE +assignees: '' + +--- + +If your feature need figuring out how to implement it or needs feedback from the wider comunity, please open a [Discussion](https://github.com/rpm-software-management/rpm/discussions) instead. If the discussion has solidified into a plan of action it is time to create an issue for actually implementing it. Unless someone is committing to doing that same work in Discussions, we should not be telling people to go there. Discussions should not be treated like that. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#discussion_r1444584514 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 Issue templates for Bug reports and RFEs (PR #2823)
@Conan-Kudo commented on this pull request. > @@ -0,0 +1,22 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: RFE +assignees: '' + +--- + +If your feature need figuring out how to implement it or needs feedback from the wider comunity, please open a [Discussion](https://github.com/rpm-software-management/rpm/discussions) instead. If the discussion has solidified into a plan of action it is time to create an issue for actually implementing it. I don't think that's necessary, since Issues can be converted into Discussions and back. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#discussion_r1443692028 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, first public draft for commenting (Discussion #2374)
Group tag is still used by the Mandrake family (Mageia, OpenMandriva, PLD, ALT, etc.). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8024703 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: Make `%setup` work with archives regardless of inner structure (Issue #2664)
Not quite. If it contains a single entry, strip it. Always create the directory `%name-%version` and extract into it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2664#issuecomment-1877539519 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: Make `%setup` work with archives regardless of inner structure (Issue #2664)
Yup. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2664#issuecomment-1877538632 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: Make `%setup` work with archives regardless of inner structure (Issue #2664)
I believe we have to inspect it to check. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2664#issuecomment-1877526112 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: Make `%setup` work with archives regardless of inner structure (Issue #2664)
> Note that because of compatibility concerns, we'd probably want this new > behavior in a new macro. We could make `%autosetup` use this behavior by default when `-n` isn't present, though. It's a "do-what-I-mean" change that would be beneficial for most. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2664#issuecomment-1874359095 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: Deduplicate data among binary packages produced by the same source package in the rpmdb (Issue #2827)
With more and more packages, especially in the distributions that do library subpackaging by soname (such as openSUSE, Mageia, and OpenMandriva), there's a lot of data that comes from the source package that has duplicate entries in the rpmdb per binary package. The largest offender of this is the changelog data, but sometimes also license tags and a few other things wind up being the same. A nice optimization for this would be to have a skeleton "source package" rpmdb entry with that data and put the common data there and have the binary package entries in the rpmdb link to that. This can lead to significant shrinkage of the rpmdb depending on distro policy on packaging. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2827 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] File conflicts: Symlinked directories -> same file replaced by real directories -> unique files (#1458)
But you shipped it and then unshipped it, so now you can't even do mock or chroot builds of those releases. If handling stuff like this is properly fixed in RPM, there's no reason to not have some way to emit those `rpmlib()` capabilities either. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1458#issuecomment-1851936907 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] File conflicts: Symlinked directories -> same file replaced by real directories -> unique files (#1458)
If we can solve this somehow, can we also bring in the old `rpmlib()` things from [this patch](https://src.fedoraproject.org/rpms/rpm/blob/f20/f/rpm-4.10.90-rpmlib-filesystem-check.patch) so that dnf installroot installs for affected distributions don't fail like this? ``` Running transaction check Error: transaction check vs depsolve: rpmlib(X-CheckUnifiedSystemdir) is needed by setup-2.8.48-1.fc17.noarch rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-3-2.fc17.x86_64 To diagnose the problem, try running: 'rpm -Va --nofiles --nodigest'. You probably have corrupted RPMDB, running 'rpm --rebuilddb' might fix the issue. ``` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1458#issuecomment-1830850932 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] Declarative buildsystem, take II (PR #2774)
@Conan-Kudo requested changes on this pull request. > +%buildsystem_python_build +``` + +## Supporting new build systems + +Supporting new build system types is just a matter of declaring a few +macros for the build scriptlet sections relevant to the build system. + +Scriptlet | Mandatory | Buildsystem macro +--- +`%prep` | No| `%buildsystem_name_prep` +`%conf` | Yes | `%buildsystem_name_conf` +`%generate_buildrequires` | No| `%buildsystem_name_generate_buildrequires` +`%build` | Yes | `%buildsystem_name_build` +`%install`| Yes | `%buildsystem_name_install` +`%check` | No| `%buildsystem_name_install` ```suggestion `%check` | No| `%buildsystem_name_check` ``` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#pullrequestreview-1744225951 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: file triggers v2 (Issue #2655)
We should support all the same features for a file list entry here, which also means being able to handle regular expressions. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2655#issuecomment-1798345651 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 declarative autobuild system (prototype) (PR #2620)
`BuildSystem`, `BuildType`, and `BuildOption(stage)` makes sense to me. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1794452101 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: introduce an rpm-controlled per-build directory to builds (Issue #2078)
Couldn't we just make `%setup -c` the default behavior and then strip the top level directory automatically when extracting an archive? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2078#issuecomment-1792049118 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] Disallow most control characters in at least %summary, %description and %changelog (Issue #2742)
I thought we already disallowed these at some point? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2742#issuecomment-1792046552 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 %_sharedstatedir to %{_var}/lib (PR #2743)
@Conan-Kudo approved this pull request. I do this in `debbuild`, I didn't realize we never fixed it in RPM. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2743#pullrequestreview-1712040562 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 declarative autobuild system (prototype) (PR #2620)
`AutobuildOption(conf):` could just be a repeatable tag, no? That's how the `ExclusiveArch`, `ExcludeArch` , and the dependency tags work. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1792022219 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 declarative autobuild system (prototype) (PR #2620)
> You mean a spec tag, like `AutobuildConfOpts: --some-opts here`? I dunno. The > tags look even uglier to me than the macros, and macros is what the > implementations need to deal with anyhow. I guess, it's just that a spec tag field is standardized, whereas a macro is not. Macro names can be anything at all and there are no real rules or discovery mechanisms for them. And if we're talking about handling the basic case in a reasonably sane way, then being able to pass autobuild configuration options in a uniform fashion would be nice. I'm not totally married to the idea of it being a spec tag though. It just feels like doing so would enforce more consistency. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1790550120 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 declarative autobuild system (prototype) (PR #2620)
Why not define it as a field instead of a macro? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1790520257 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 declarative autobuild system (prototype) (PR #2620)
Would it make sense to be able to expose some kind of simple way to pass options to the configure stanza? Autotools, CMake, and Meson at least all accept configure options, and it'd make sense to be able to do this without having to override the whole stage. A similar example of something like this is in Flatpak, where you declare the buildsystem type and then declare the options to be passed in. For example [Lugaru's manifest](https://github.com/flathub/io.gitlab.osslugaru.Lugaru/blob/master/io.gitlab.osslugaru.Lugaru.json) sets the buildsystem to "cmake-ninja" and then has a field for setting extra options. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1788843684 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 declarative autobuild system (prototype) (PR #2620)
It does probably make sense to pull the CMake macros into rpm so we can build ourselves from what is provided by rpm itself... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1783016528 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] WIP: Use Python Stable ABI for the bindings (PR #2674)
As it stands, we gracefully fall back to the current behavior anyway, so I don't think the CMake stuff is a reason to hold up this PR. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2674#issuecomment-1740870818 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] WIP: Use Python Stable ABI for the bindings (PR #2674)
Well, I guess then we should hope for [my CentOS Stream MR](https://gitlab.com/redhat/centos-stream/rpms/cmake/-/merge_requests/11) to be merged? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2674#issuecomment-1740838362 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] WIP: Use Python Stable ABI for the bindings (PR #2674)
@pmatilai I would just backport the FindPython module and conditionally use it if CMake is too old. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2674#issuecomment-1740820797 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] WIP: Use Python Stable ABI for the bindings (PR #2674)
> With CMake 3.26+, stable ABI will be used by default. This is fine, we can work in subsequent PRs to handle it internally for older CMake versions. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2674#issuecomment-1738117094 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: Standardize on OCI images for test-suite, even locally (Issue #2643)
Well, apparently this is now a thing: https://macoscontainers.org/ -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1736575490 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] Increment build date every release (PR #2677)
The changelog bumps for every build, even no-change rebuilds. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1733638621 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] Increment build date every release (PR #2677)
Never. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1733637577 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] Increment build date every release (PR #2677)
The correct fix for openSUSE is that the OBS builder should generate a new `SOURCE_DATE_EPOCH` number to pass into the rpmbuild environment and you should _not_ set `%source_date_epoch_from_changelog 1`. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1732230398 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] Increment build date every release (PR #2677)
Oh, I misunderstood, this is about files inside of the package, not the RPM itself. I don't think this change is a valid one, because you're basically asking for RPMs to be automatically because your process flow includes automatic rebuilds that don't bump changelogs. That's what setting `SOURCE_DATE_EPOCH` externally is for. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1732229913 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] Increment build date every release (PR #2677)
The fix is to _not_ clamp buildtime to SOURCE_DATE_EPOCH (i.e. don't set `%use_source_date_epoch_as_buildtime 1`). We don't do this in Fedora and I don't recommend any distribution to do it if they have a pipeline that relies on the buildtime (and the openSUSE pipeline definitely does). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2677#issuecomment-1732228211 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] Fail test image build on cmake failure (Issue #2667)
The container environment is reused for each step in a "job", but each job is separate. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2667#issuecomment-1724681265 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 signature verification for files from installed packages (Issue #2671)
> The issue however is neither Fedora, nor RHEL keeps intermediate update > packages on the server, so it's quite a common configuration to have packages > are installed where the source Fedora/RHEL packages cannot be downloaded or > found anywhere on the Internet since they have been deprecated and replaced > with newer updates. Two things: 1. RHEL does keep intermediate packages published forever. RHEL derivatives may not necessarily do that, though. 2. Fedora has a huge archive repo that is not shipped/enabled by default that keeps all shipped updates for a release. If you install the `fedora-repos-archive` package, you'll get the updates archive. It's used by Fedora CoreOS primarily, but it's available to any Fedora user to use optionally. That said, the problem you describe is potentially worth solving regardless. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2671#issuecomment-1724679899 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: Standardize on OCI images for test-suite, even locally (Issue #2643)
> None of this is inherently Linux specific, however to make it reasonably fast > and efficient, you need something like OverlayFS which is currently only > available on Linux (and > https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-165921 > on some BSDs through fuse-overlayfs but that's likely slower than a native > kernel implementation). [FUSE exists on macOS too](https://osxfuse.github.io/), though I don't know if `fuse-overlayfs` works with it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1719473973 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: Standardize on OCI images for test-suite, even locally (Issue #2643)
I will also point out there are openSUSE containers that use DNF too. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1718407495 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: Standardize on OCI images for test-suite, even locally (Issue #2643)
Keep in mind, we need a way to run it directly on the host, because all this fanciness you're talking about doesn't exist on non-Linux platforms. In particular, I would like to be able to run the test suite for RPM on macOS still. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-1718407103 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 `%setup` work with archives regardless of inner structure (Issue #2664)
Note that because of compatibility concerns, we'd probably want this new behavior in a new macro. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2664#issuecomment-1718404293 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] Make `%setup` work with archives regardless of inner structure (Issue #2664)
In a conversation in [`#devel:fedoraproject.org`](https://matrix.to/#/#devel:fedoraproject.org) with @penguinpee, I realized that there's a potential quality of life improvement we could look into making around `%setup`: Making it so we don't ever need to use `-n`. It started with asking about how to pass in `--strip-components=1` to `%setup`, and I realized something: now that libarchive exists, it would be possible for us to have a universal unarchiver program with RPM that can give us the ability to automatically handle extracting archives properly, regardless of what the name of the top level directory is or whether there is even one at all. For some prior art, Debian's packaging tooling can do this, and it uses that to 1) extract the tarball into a `name-version` directory, and 2) blow away `debian` directory of an upstream tarball if it exists so its own version can be unpacked in-tree. Obviously, we don't need to do the second thing, but the first thing would be extremely useful. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2664 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 a new perl.prov script to generate normalized module versions (PR #2586)
cc: @ppisar -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2586#issuecomment-1715005987 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 to support perl normal version scheme for rpm compatible versions (PR #2609)
cc: @ppisar -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2609#issuecomment-1715005576 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] Eliminate RPMDBI_SIGMD5 and RPMDBI_SHA1HEADER rpmdb indexes (Issue #2633)
Yes. I think Koji did at one point, and OBS does last I checked. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2633#issuecomment-1703681477 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 declarative autobuild system (prototype) (PR #2620)
I think this is going to need a versioned rpmlib capability, at least for SRPMs. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1690307448 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: read sources checksums from the SPEC file and verify them (#463)
I like that and would love to see an implementation for it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/463#issuecomment-1474042087 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: convert absolute symlinks to relative ones (#668)
Also, another example of this is [`dh_link`](https://salsa.debian.org/debian/debhelper/-/blob/main/dh_link). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/668#issuecomment-1473842326 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: convert absolute symlinks to relative ones (#668)
> Another thought on the subject is that we could have a brp-script that turns > absolute links into relative ones. This might be possible with the [`symlinks(1)`](https://www.mankier.com/1/symlinks) tool? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/668#issuecomment-1473822710 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] cmake: Fix rpm vendor setting and drop enforced "redhat" vendor (PR #2440)
Will do! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2440#issuecomment-1473811240 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] cmake: Fix rpm vendor setting and drop enforced "redhat" vendor (PR #2440)
There are other bugs related to the platform setup, but I haven't figured out how to fix them yet. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2440#issuecomment-1473808289 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] cmake: Fix rpm vendor setting and drop enforced "redhat" vendor (PR #2440)
Somehow across the Autotools-CMake migration, we accidentally dropped the configurability of the RPM vendor and always set it to redhat. Restore the configuration knob with a CMake variable and eliminate the circular setting in the CMakeLists that blows away what the user sets. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2440 -- Commit Summary -- * cmake: Fix rpm vendor setting and drop enforced redhat vendor -- File Changes -- M CMakeLists.txt (5) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2440.patch https://github.com/rpm-software-management/rpm/pull/2440.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2440 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] RPM v6 package format, first public draft for commenting (Discussion #2374)
probably not `tar`, but why not `pax`? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5230414 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 should not use short gpg key ids in messages (Issue #2403)
> Well, anything which parses this output and makes use of it is broken. I > shouldn't be using short ids for anything, particularly not in a script. So I > think it's entirely reasonable to just change the output. Unfortunately, we can't afford to do that. There are config management tools and layered package managers that parse RPM's output. And we have the model of "it's stable unless documented otherwise". So we have to work with that. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2403#issuecomment-1454895024 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
