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

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:

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.

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.

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: ___

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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

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 +#

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

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:

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

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:

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:

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:

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

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:

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

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

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

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

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

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:

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:

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:

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:

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.

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

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

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

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?

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

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:

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: ___

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

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

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

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)

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:

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:

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:

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

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

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

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

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

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:

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

[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

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

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

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 |

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

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:

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

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:

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

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

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

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:

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

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

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

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

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

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

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:

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:

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

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:

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

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). --

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.

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

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

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:

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:

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

[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

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

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

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:

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:

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:

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

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:

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

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

[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,

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:

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

  1   2   3   4   5   6   7   8   9   10   >