This was an awful patch. For somebody who has been using rpm since its
inception the sudden and irretrievable disappearance of build tree is terrible.
It is not unusual to run "-ba" then after successful build go back to build
tree and make some changes or develop a patch. Or try an figure out
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
On requests is reported NET::ERR_CERT_COMMON_NAME_INVALID
```console
NET::ERR_CERT_COMMON_NAME_INVALID
Subject: *.osuosl.org
Issuer: InCommon RSA Server CA
Expires on: 14 Aug 2024
Current date: 28 Nov 2023
PEM encoded chain:
-BEGIN CERTIFICATE-
I'd pull the whole rpm2archive improvement bunch (except the actual replacing
of rpm2cpio I guess)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2791#issuecomment-1829880268
You are receiving this because you are subscribed to this
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2791
-- Commit Summary --
* Drop no longer needed pull from updates-testing for rpm-sequoia
* Split our include_directories() per use-case, comment
* Move top-level
Closed #2790.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2790#event-11083319753
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Ugh, not against master...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2790#issuecomment-1829801927
You are receiving this because you are subscribed to this thread.
Message ID: ___
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2790
-- Commit Summary --
* Use mkdir -p for creating SPECPARTS dir
* Fix undefined symbols from plugins in some circumstances
* Revert %_smp_build_ncpus change to a
@pmatilai converted this issue into discussion #2789.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1482#event-11082570451
You are receiving this because you are subscribed to this thread.
Message ID:
This is actually a quite powerful. Try this:
```
%define hey() {
this is hey
%{shescape %**}
%**
ho
}
%global array foo bar %{quote:hello world} %%{quote:huhu foo}
%global xx x1 %{quote:x2 x3}
%global array %array %{quote:aa %%xx} %%xx
%global array %array %{quote:rpm is great} rpm is
@mlschroe pushed 1 commit.
affb2e8d2e460c6e25dd579eac0f36822da0fa3e Strip quote characters in macro
expansion if we do not split the result
--
View it on GitHub:
A problem with the old handling of %quote was that it leaked to the outside.
This commit strips the quote characters if they are not used in argument
splitting.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2788
--
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2787
-- Commit Summary --
* fix: resource leak: f
-- File Changes --
M tests/rpmpgppubkeyfingerprint.c (6)
-- Patch Links --
> > @kanavin Are all of the RPMs used also built locally? In that case
> > disabling signature checking is fine.
>
> Yes of course. Yocto is fully self-contained, except for the bootstrap items
> mentioned above. It builds components from source, then makes its own
> packages from the
> @kanavin Are all of the RPMs used also built locally? In that case disabling
> signature checking is fine.
Yes of course. Yocto is fully self-contained, except for the bootstrap items
mentioned above. It builds components from source, then makes its own packages
from the binaries, then makes
Closed #2785.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2785#event-11080627949
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
The reason for getting rid of the internal OpenPGP parser is that it turns out
to have security vulnerabilities that are exploitable if someone does `gpg2
--export --armor -o s.asc FINGERPRINT && rpmkeys --import s.asc`. Patching
these vulnerabilities isn’t practical, as it would require a
@kanavin Are all of the RPMs used also built locally? In that case disabling
signature checking is fine.
FYI, both rustc and clang are native cross compilers with support for multiple
targets. The same rustc and clang that are used to compile programs for the
build environment can also be
@slark-yuxj pushed 1 commit.
fa9e7290f1b6146d7bfc46d26539a4681789c259 Update rpmpgppubkeyfingerprint.c
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2785/files/1464bcf938d9771f9874dcb07b3a994fedfd3959..fa9e7290f1b6146d7bfc46d26539a4681789c259
You are receiving this
Compliance expectations for audit require even attempted installs of packages
with bad signatures and the like to be audited, but not for queries. This is
currently rather impossible to enforce on the API level as everything needs to
go through rpmReadPackageFile() where bad header signature
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2785
-- Commit Summary --
* fix: resource leak: f
-- File Changes --
M tests/rpmpgppubkeyfingerprint.c (5)
-- Patch Links --
> > Using host distro tools in cross-compilation builds is problematic, as we
> > don't have control over what versions we're going to get, and how they are
> > built and configured. To ensure things work in a reproducible manner, yocto
> > builds its own rpm executable that can run on the
> > > So Yocto can accept that regression in package security, we'll make sure
> > > to place warnings where appropriate.
> >
> >
> > Another option would be to use the host system’s RPM for verifying the
> > packages.
>
> Using host distro tools in cross-compilation builds is problematic, as
> > So Yocto can accept that regression in package security, we'll make sure to
> > place warnings where appropriate.
>
> Another option would be to use the host system’s RPM for verifying the
> packages.
Using host distro tools in cross-compilation builds is problematic, as we don't
have
24 matches
Mail list logo