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
> 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
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
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
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:
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
@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: ___
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:
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:
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
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:
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
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.
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:
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
@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
> 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
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
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:
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
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:
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
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,
> 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
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
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
> 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,
>
> 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
> 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,
> 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
30 matches
Mail list logo
