**RPM v4.16.1** (in RHEL v9)
I have some RPMs that use Triggers and deploy some files
For various reasons, I want to "update" the RPMs - that is, I want to "remove"
the "old" ones and "install" the "new" ones. In a few cases, the RPMs are
changing names (even though the "old" RPM does exactly
Thank you all for so many comments. I am sorry for being inactive on this PR
for a while. I was partially on vacation and now trying to catch up. I will
update the PR soon.
--
Reply to this email directly or view it on GitHub:
Thanks for the suggestions! Indeed, going one directory upwards would've been
the solution (and I had a working patch for that already)... except then I
realized the root cause was actually a bit different. We weren't populating the
package's dirname list (when processing relocations) correctly
Unbreak installation and removal of relocatable packages that own the `/` path
(like in [RHEL-28967](https://issues.redhat.com/browse/RHEL-28967)). This
happened to work before #1919 but just by accident, see the commit
messages for details.
Fixes: #3173
You can view, comment on, or merge this
Each library targets exported `INTERFACE_INCLUDE_DIRECTORIES` list, as
written into the `rpm-targets.cmake` export file, is controlled by the `PUBLIC`
arguments supplied to `target_include_directories()` for the library target.
* Directories scoped with the `$BUILD_INTERFACE` generator
Whoops. Actually, ignore that first patch, I typo'd a `%{buildroot}` as
`${buildroot}`.
_Fixed_ updated patch:
[pkcs11-provider_spec.patch.txt](https://github.com/user-attachments/files/16428873/pkcs11-provider_spec.patch.txt)
--
Reply to this email directly or view it on GitHub:
Note that the diff above is no longer valid, as the spec has been converted to
build with meson, so it won't apply cleanly (or even uncleanly).
Updated patch:
[pkcs11-provider_spec.patch.txt](https://github.com/user-attachments/files/16428678/pkcs11-provider_spec.patch.txt)
(No idea why I had
Maybe they're related but it doesn't seem like the same issue to me.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3216#issuecomment-2258298615
You are receiving this because you are subscribed to this thread.
Message ID:
Yet another thought: maybe what the existing code unintentionally does is not
so bad: it basically fades out the phony "X is better than Y" comparison
between RSA and (EC)DSA, which is particularly silly when only one of them will
ever be present in a single package. Ie you just fix the
Tested locally (with `cmake --build _build --target ci`), seems to pass
reliably.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3221#issuecomment-2258204216
You are receiving this because you are subscribed to this thread.
Message ID:
So ... maybe we're better off looking at this in the context of other signature
changes coming for v6, and concentrate on those 4.20 matters just now instead.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3194#issuecomment-2258157229
Other remarks found from the dusty archives while poking around this area in my
head:
IIRC the reason the transaction verify reports the first issue found is that in
that context, there's no point continuing. And so, you can just report the
first error found. Or so the theory goes, clearly the
@pmatilai commented on this pull request.
> /* Take care not to override a previous failure with success */
- if (res > vd->type[sinfo->type])
- vd->type[sinfo->type] = res;
+ if (severity > vd->type[sinfo->type]) {
+ vd->type[sinfo->type] = severity;
Ehm,
I wonder if there isn't a saner way to handle the legacy compat thing of
allowing unsigned packages.
Especially going forward to a future where unsigned packages are only
installable with --nosignature. It's not like we *have to* have this fixed in
4.20, it's been there six years already...
--
@ferdnyc pushed 1 commit.
82e03b12622f5b579ff4376199a18ecc33c7e808 Add .editorconfig, and note in
CONTRIBUTING doc
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3219/files/32e5c98305d72d5da25b9627c12d4918598e0fd5..82e03b12622f5b579ff4376199a18ecc33c7e808
You are
@pmatilai commented on this pull request.
> /* Take care not to override a previous failure with success */
- if (res > vd->type[sinfo->type])
- vd->type[sinfo->type] = res;
+ if (severity > vd->type[sinfo->type]) {
+ vd->type[sinfo->type] = severity;
/bin/false exits so fast that racing with the parent output order is a
fifty-sixty situation at best. Use a purpose-made shell script that does a bit
of IO and even sleeps a bit, which together with shell startup time should be
plenty enough to guarantee stable output for most practical
Merged #3218 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3218#event-13691564991
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Didn't try locally rendering but the explanations make sense - this doc started
life in 1997 (4252a906d1c1c0e89314a231ff3e7550507a8580) as a plain ASCII text
and has since gone through at least a Doxygen phase before the move to Markdown
in recent years, with multiple people leaving their
Fresh back from vacation as of yesterday...
There was a tiny memory leak from pre-existing code causing the tests to fail
now that it actually got exercised with rpm-sequoia 1.7. I created a separate
#3220 for testing it in case there was something else that needed tweaking but
one missing
Closed #3202.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3202#event-13691426643
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Merged #3220 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3220#event-13691376632
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
#3202 is failing due to a memory leak in code previously not exercised by CI,
lets see if theres more stuff needed...
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3220
-- Commit Summary --
* Fix minor memleak introduced
I just got
```
+++ /srv/rpmtests.dir/at-groups/12/stderr 2024-07-30 07:20:13.111240868
+
@@ -1,3 +1 @@
-error: Executing url helper "/bin/false rpm-tmp
https://example.com/foo-0.1-1.noarch.rpm; failed with status 1
-error: open of https://example.com/foo-0.1-1.noarch.rpm failed: No
Dnf is not the best of sources for rpm API usage. It does most of its work on
the libsolv level rather than rpm, and the little rpm API usage there is
suffers from the yum heritage.
--
Reply to this email directly or view it on GitHub:
25 matches
Mail list logo
