Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
> One of the SUSE list members mentioned that they want to continue to be able > to use LEAP packages as dependencies, and I think this approach addresses > that concern. Is it about using library packages from Leap (old) on Tumbleweed (new)? If so, I'd argue that is simply invalid and basically what this approach should protect against. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2008954902 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
@mlschroe , thoughts on this? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2008964003 You are receiving this because you 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] Uninformative error message on %include'd and generated spec content (Issue #2714)
Not going to do major refactoring for this in 4.20, drop the milestone. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2714#issuecomment-2008969429 You are receiving this because you 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] Reimplement distcheck target in cmake (Issue #2241)
No particular reason this needs to be in 4.20 exactly. Lets just drop the milestone, this is a "gets done when it gets done" item really. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2241#issuecomment-2008970624 You are receiving this because you 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 building other projects as part of test image (Issue #2877)
Seems I dropped the ball here, sorry. I suppose a custom base image could be handy. It doesn't scale though, eg in case we'd want to build rpm-sequoia, popt and .. say, elfutils from sources to test a new feature before it's packaged in Fedora. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2877#issuecomment-2008989166 You are receiving this because you 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: native support for vpath builds (Issue #2985)
With the new rpm-controlled %builddir from #2078, we now have a safe playground for all sorts of things that didn't have a place to go before. One such item is vpath (aka out of tree) builds, whereas rpm traditionally always assumes build happens inside the source tree. What once was the defacto thing is nowadays frowned upon (for good reasons), and the once fancy-pants vpath build is closer to the norm. We can never change the default %setup behavior without breaking tonnes of packages, but we should support the vpath build natively as an opt-in: unpack sources as usual but create and change to an empty directory fully outside the source tree for the build. This could be something new Buildsystem: implementations might want to take advantage of, for example. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2985 You are receiving this because you 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] Could the default %clean section remove non-readable+non-empty directories? (Issue #2519)
Another case where we'll run into this is if/when we add support for vpath builds in read-only tree (#2985). The default `%clean` is a macro now, making this kind of thing easy. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2519#issuecomment-2009015669 You are receiving this because you 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: elfdeps: Filter Python subdirectories (#1227)
This is a sub-case of the more general issue tracked now in #2922, closing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1227#issuecomment-2009029344 You are receiving this because you 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: Fix license permissions (#1090)
This should be done together with #567. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1090#issuecomment-2009033180 You are receiving this because you 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: Fix doc permissions (#567)
The same goes for %license, with a slight difference: while documentation may sometimes be executable (example scripts), licenses never can. The two are closely related though so there's no point having separate tickets for the two, closing #1090 in favor of this. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/567#issuecomment-2009037533 You are receiving this because you 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: Fix license permissions (#1090)
Actually, makes more sense to just merge this into #567. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1090#issuecomment-2009039428 You are receiving this because you 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: Fix license permissions (#1090)
Closed #1090 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1090#event-12181293275 You are receiving this because you 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] Upstream relevant bugs from Fedora bugzilla + document it (Issue #2099)
Closed #2099 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2099#event-12181400165 You are receiving this because you 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] Upstream relevant bugs from Fedora bugzilla + document it (Issue #2099)
This can be considered accomplished now, just need to maintain the situation going forward. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2099#issuecomment-2009054656 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow building rpm without OpenPGP support (PR #2984)
Okay, best to just get this out of the way... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2009249611 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow building rpm without OpenPGP support (PR #2984)
Merged #2984 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2984#event-12182799253 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)
@pmatilai commented on this pull request.
> - 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);
Oh and FWIW, I would love to get the full build paths somehow abstracted out
anyhow. I don't know how much is really doable in that space, but on systems
that support this kind of stuff, builds would run temp directory inside their
build directory and writes limited to their own build directory, bind-mounted
so that the build thinks its running in /build directory instead of
/home/whatever/somewhere path etc.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#discussion_r1531861031
You are receiving this because you 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] Split the internal OpenPGP parser to a separate repository (PR #2986)
Finally. See commit messages for details. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2986 -- Commit Summary -- * Prepare to cutting out the internal OpenPGP parser for good * Split off the internal OpenPGP parser to a separate repository -- File Changes -- M CMakeLists.txt (1) M INSTALL (8) M rpmio/CMakeLists.txt (7) D rpmio/rpmpgp_legacy/CMakeLists.txt (15) D rpmio/rpmpgp_legacy/digest_libgcrypt.c (445) D rpmio/rpmpgp_legacy/digest_openssl.c (691) D rpmio/rpmpgp_legacy/rpmpgp_internal.c (1423) D rpmio/rpmpgp_legacy/rpmpgp_internal.h (50) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2986.patch https://github.com/rpm-software-management/rpm/pull/2986.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2986 You are receiving this because you 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] Split the internal OpenPGP parser to a separate repository (PR #2986)
And RIP :headstone: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2986#issuecomment-2009417967 You are receiving this because you 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] Split the internal OpenPGP parser to a separate repository (PR #2986)
Merged #2986 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2986#event-12183852221 You are receiving this because you 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] Remove the internal OpenPGP parser (Issue #2414)
Closed #2414 as completed via 63e369cd3579114a011d3fd5eafaeafa8b1b2e88. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2414#event-12183852540 You are receiving this because you 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] Remove the internal OpenPGP parser (Issue #2414)
> I'm in favor of an separate project. I'm willing to take maintainership if > nobody else steps up... @mlschroe , shall I transfer the ownership of https://github.com/rpm-software-management/rpmpgp_legacy to you? Otherwise I'll just archive the thing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-2009442502 You are receiving this because you 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] `define(name, body)` documentation does not align with implementation (Issue #2962)
Indeed, rpm.define() calls rpmDefineMacro() which is takes the macro name and the body as a single line - as you would get in a macro file. It doesn't make much sense as an API. IIRC Lua's rpm.define() used that API because the other alternative lacked all the error checking back in the day, but things are quite different now, Lua should get a better define macro. Note that this also works: `macros['foo'] = 1` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2962#issuecomment-2009523484 You are receiving this because you 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] `define(name, body)` documentation does not align with implementation (Issue #2962)
For the context, I have stumbled upon this issue playing with #2969 and my initial idea was to assign the whole macro body including the new lines to some macro with some specifically crafted name. But I was not able to achieve that no matter what and resorted to use variables (which is probably good enough variant). It is my feeling that for whatever reason defining macro in Lua is limited comparing to plain .spec file, not being able to insert new line there. But maybe I have just not figured out the right amount of backslashes or what not. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2962#issuecomment-2010097636 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
> Is it about using library packages from Leap (old) on Tumbleweed (new)? If > so, I'd argue that is simply invalid and basically what this approach should > protect against. It's not *necessarily* invalid. In Fedora, packages that fail to build from source are eventually retired along with all of their dependencies, and (basically) everything is rebuilt for every release, so we wouldn't expect old libraries to mix with new applications, there. But if SUSE doesn't retire those packages, then they could continue using an older library package in a new build root, when they build a new application that depends on an old library. In the previous version of this PR, the new binary would express a dependency that the library's package doesn't provide. In this version, packages won't express that dependency on libraries that don't provide it, because they won't have a ".elf-version" file. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2010126829 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
> In Fedora, packages that fail to build from source are eventually retired > along with all of their dependencies, and (basically) everything is rebuilt > for every release, so we wouldn't expect old libraries to mix with new > applications, there. But if SUSE doesn't retire those packages, then they > could continue using an older library package in a new build root, when they > build a new application that depends on an old library. For Leap vs. Tumbleweed there's a ~6y gap for some packages so I don't expect any compatibility there. What can happen is that e.g Leap 15.6 with this PR builds an application against a library from 15.5 built without this PR. That still needs to be installable, either using your `.elf-version` approach or maybe some other that inspects which capabilities the library provides. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2010359486 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
> What can happen is that e.g Leap 15.6 with this PR builds an application > against a library from 15.5 built without this PR. That still needs to be > installable /me nods With the .elf-versions file approach, it would be. The library from 15.5 wouldn't have the .elf-versions file, so any application built in a 15.6 build root where that package was present would simply continue to express the same type of un-versioned dependency that it does today. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2010472935 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
The other thing I'm wondering is whether we can (or should) label the .elf-version files, so that package managers can skip installing them, the same way that documentation is not installed in container images (RPMTRANS_FLAG_NODOCS). The .elf-version files aren't needed at runtime, they're only needed in build roots. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2010481742 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
> The other thing I'm wondering is whether we can (or should) label the > .elf-version files, so that package managers can skip installing them, the > same way that documentation is not installed in container images > (RPMTRANS_FLAG_NODOCS). The .elf-version files aren't needed at runtime, > they're only needed in build roots. It's arguably package metadata and doesn't belong in the filelist at all if possible IMO -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2010490504 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
> It's arguably package metadata and doesn't belong in the filelist at all if > possible IMO Generally, I agree, but I'm operating on the principal that elfdeps shouldn't access the RPM DB during the build. (And if we did access the DB for metadata, I'm not sure how we'd allow packagers to override the version. Would we need to introduce a new field?) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2010538686 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
