On 2/18/26 4:13 PM, Cristian Le via devel wrote:
On 2026/02/18 15:00, Panu Matilainen wrote:
On 2/18/26 2:27 PM, Cristian Le via devel wrote:
On 2026/02/11 16:06, Panu Matilainen wrote:
Hi Panu,
I can now confirm that we are indeed hitting this issue. Afaik we did
set gpgcheck=0, and I am now digging into the code to confirm this.
Here are some failed jobs to reference:
- Copr artifact: https://artifacts.dev.testing-farm.io/
d3f1db58-2964-42d0-be60-9c6023d6acd4/ (inside "Copr build(s)
installation" -> "6-Install-pakcages.txt")
- Koji artifact: https://artifacts.dev.testing-farm.io/
a33f815a-9021-42d0-8fa5-8afefcc8da44/
Also see the "4-Add-repository.txt" I do see `gpgcheck=0`.
Okay so here at least, the issue is that the package file that is
failing the check is specified on the command line directly, so no
repository configuration affects that.
Thanks, I've highlighted that issue. It is partly an implementation
issue because we are somehow trying to make sure the exact rpms are
being used instead of relying on the priority, --from-repo, etc. flags.
We'll keep that in mind in the redesign.
Note that this package IS signed, it's just that the key is not imported:
- package python3-scikit-build-
core-0.11.6-1.20260217085946639536.pr1219.48.g8dce8a6.fc45.noarch does
not verify: Header OpenPGP V4 RSA/SHA256 signature, key ID
e2b551f502810203: NOKEY
The test is downloading the copr repo definition which includes the
key info as well:
gpgkey=https://download.copr.fedorainfracloud.org/results/packit/
scikit-build-scikit-build-core-1219/pubkey.gpg
Thanks, it seems that that is not set properly, will try to see if we
can add it for the future.
The issue here is that no repo config will be used for installing a
package whose location you specify on the command line. So nothing wrong
with how it's set AFAICS, the issue is with the command line *use*.
The brute-force variant is of course to just disable signature
checking for that bit.
One would expect --setopt=localpkg_gpgcheck=false to the command line
bypass that, but that doesn't seem to work. Which would be a dnf bug.
I'll have a look.
Hmm, that goes for --no-gpgchecks as well. Which was intentional back
in 2018 but not so much now.
Hmm, but are all installation from @Commandline supposed to be signed
and checked with the new change proposal?
Yes, ALL package installs going through librpm, regardless of the
"client" used. So including rpm itself of course, dnf/dnf5, a homegrown
python install script - everything.
To workaround, override the rpm policy in the test running
environment, as per the change docs:
# echo '%_pkgverify_level digest' > /etc/rpm/macros.verify
This might be the best approach.
That gives you the exact former behavior if you need time to sort things
out. Going forward, it's not the best option.
Just to double check, `/etc/rpm/
macros.verify` was something that was newly introduced with this
proposal and it is ok to completely overwrite it?
That file does not normally exist. It's just an arbitrary name for a
host-wide rpm configuration macro file.
- Panu -
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
