On 2/18/26 2:27 PM, Cristian Le via devel wrote:
On 2026/02/11 16:06, Panu Matilainen wrote:
On 2/11/26 4:06 PM, Cristian Le via devel wrote:
We expect this will break testing-farm tests almost immediately
because we are using the koji artifacts which are unsigned. Can you
provide some guidance on how to get ready for this as fast as
possible? [1] Is there something that can be setup in the `.repo`
file to disable this check?
Setting pkg_gpgcheck=0 (aka gpgcheck=0) in the .repo lets you install
unsigned packages. That's how mock etc operate, and keep working over
this change.
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.
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
So ideally, you'd download any gpgkey= from the copr repo and import it,
and then it'll just work.
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.
To workaround, override the rpm policy in the test running environment,
as per the change docs:
# echo '%_pkgverify_level digest' > /etc/rpm/macros.verify
I don't know how all that is structured so hard to give guidance on it,
but that needs to happen before any commands that attempt to install
local package files with dnf.
Can we check on what is going on here? Are we misconfiguration this or
is this an issue with the implementation?
I don't know what the story behind that "local" plugin is, but there
seem to be various workaround suggested?
The issue with dnf local plugin is different, and I suspect that the
change they have made there will impact the users. It seems to be an
opt-in feature at least, but it is a bug in dnf implementation iiuc. We
reported this in upstream https://github.com/rpm-software-management/
dnf5/issues/2580
Ok.
- P
--
_______________________________________________
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
