Lots of packages remove .la files via
find $RPM_BUILD_ROOT -name *.la -delete
or similar. Add %remove_installed_la_files to standardize this.
I could not find tests for the macros in the rpm repository, but I testes this
separately in a spec file. I went with `-delete` here and not `exec rm
Through a combination of manual audits and fuzzing, I found several
vulnerabilities in RPM:
- RPM does not reject packages that have a signed header, but neither a
header+payload signature nor a payload digest. Furthermore, `rpmkeys
-K` reports `digests signatures OK` for such packages. Such
@DemiMarie pushed 3 commits.
7faa67b49d434bc7b108258e2c554b63894ffe4e Header signatures alone are not
sufficient
dbd37e66e17f9ff20c04ad168c547c2cb21aabbc Fuzz harness for rpmReadPackageFile()
and pgpPrtParams()
4336c3d33e9cc372a1dbf110be92183718499002 Fix an undefined shift in the
> @DemiMarie , I don't understand what you're trying to achieve here. I've
> explained before that we'll never accept this sort of gigantic pull-request
> touching multiple unrelated corners in one gulp, and all/most of these
> patches already exists in separate pull-requests just waiting to be
FWIW, I think that deprecation+eventual removal is the way to go in this case.
If the macro was exposed, but not *actually used*, it'd be OK to quickly yank
it out. But clearly it is in use, and we know that the removal breaks packages
that are out there. I appreciate the desire to make a clean
What about this: I'll finally shut up about `%apply_patch` if you'll take a
backport of `%autopatch -n` for RPM 4.16.x and we document it as a replacement
for the removal. That way, we can update our Python spec files on Fedora 33 and
further and hopefully also in CentOS Stream 9. (I'd also
Sorry but I'm finding the level of noise and bargaining quite excessive for the
case. For an immediately backwards compatible version (for rpm >= 4.15), use
`%autopatch -m -M ` and wrap it up in a one-line local helper macro
for convenience. -n is certainly subject for inclusion in a future
This allows to apply one single patch.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1673
-- Commit Summary --
* Add the -n option for %autopatch
-- File Changes --
M macros.in (14)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/1673
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I've grepped the source three for `autopatch` and there seem to be no
documentation for the options anywhere, except the inline comment. Would you
please guide me in documenting this change?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
Adding -n is fine (funny how such obvious things don't get noticed), but I
don't want %apply_patch back, and testing for the error seems over the top,
just document -n to override -m and -M.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
This fixes how RPM handles packages that contain a header signature, but
neither header+payload signature nor payload digests. Such packages are
obviously not properly signed, but RPM previously accepted them.
This could be used to confuse both ‘rpmkeys -K’ and DNF. Both would
report that the
I am just trying to make my life easier here, nothing more. Removals have
negative impact on others :(
I'll open a PR with just `%autopatch -n`
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #1671.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1671#event-4687203347___
Rpm-maint mailing list
@DemiMarie , I don't understand what you're trying to achieve here. I've
explained before that we'll never accept this sort of gigantic pull-request
touching multiple unrelated corners in one gulp, and most of these patches
already exists in separate pull-requests just waiting to be processed.
Thanks for the info! Let me check it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1669#issuecomment-832605314___
Closed #1669.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1669#event-4688478118___
Rpm-maint mailing list
Thanks! I confirmed it works with `%{load: ...}`. I would close this ticket.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
As usual, a bit of AFK gave some helpful perspective: -n is actually a rather
strange corner-case to be considering. What makes more sense is have %autopatch
accept arguments, that way it's not limited to one-at-a-time special fubar and
can be made to handle both paths and numbers. I'll try to
@pmatilai when using `%{load:...}`, the rpmlint failed to part the spec file.
https://github.com/rpm-software-management/rpmlint/issues/632 . The rpmlint can
not detect the loaded file's existence.
I see the `%{exists...}` is still new in RPM 4.17.
http://rpm.org/user_doc/macros.html
Is there
Reopened #1669.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1669#event-4689242420___
Rpm-maint mailing list
21 matches
Mail list logo
