On 11/8/22 21:45, Adam Williamson wrote:
On Tue, 2022-11-08 at 08:11 -0800, Adam Williamson wrote:
On Tue, 2022-11-08 at 13:32 +0200, Panu Matilainen wrote:
But I don't know the slightest thing about ansible, beyond a very rough
idea of what kind of tool it is. Just understanding what exactly it's
trying to do here would go a long way, I think. But either it's not in
the logs, or I don't know how to read them.
well, to expand on my previous answer, it gets a bit interesting. At
this point in the process the CI system has installed the packages to
be tested and verified that they're installed, which implies RPM does
at least basically work or else that would have failed. you can see
this in these logs:
https://artifacts.dev.testing-farm.io/700d486d-d409-44fe-b7c3-01634243558e/guest-setup-554c73be-c472-4007-9f14-23eea462c69d/artifact-installation-554c73be-c472-4007-9f14-23eea462c69d/
then it hands off to ansible to actually 'run the tests', and that's
when the error happens. I believe it happens here in ansible's code:
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/dnf.py#L1366
so that may help you figure it out. I'd look further but I have to run
out right now...
well, I'm back now. Looking into it a bit further, I think the codepath
we're on compresses to this, where `self.base` is a DNF base object:
self.base.upgrade_all()
try:
self.base.resolve(allow_erasing=self.allowerasing)
[cut internal stuff that couldn't raise a DNF error]
for package in self.base.transaction.install_set:
fail = False
gpgres, gpgerr = self.base._sig_check_pkg(package)
[cut more stuff that couldn't raise the error]
self.base.do_transaction()
except dnf.exceptions.Error as e:
failure_response['msg'] = "Unknown Error occurred: {0}".format(to_native(e))
self.module.fail_json(**failure_response)
I'm pretty sure that's the path we're on, and "An rpm exception
occurred: package not installed" is the text of a dnf.exceptions.Error
exception that's raised by one of those actions that actually involves
the DNF base object (I cut stuff that doesn't involve it, and one
branch where we'd do something different if we hit a
dnf.exceptions.Error). Next step would be to see why dnf is throwing
that error, I guess. It'd be nice if it said *what* package it thinks
is "not installed"...
Indeed. It is an exceptional situation though.
Anyway, Maxwell G's PR showed that it is indeed a weak signature
someplace (thanks again!), and with clues learned from that I could
debug it further on my own.
https://artifacts.dev.testing-farm.io/a1c1cc94-0f2b-41f0-a0c2-2456dd50359a/work-tests.ymllY4cuv/ansible-output.txt
and the smoking gun is here:
494 python3-koji-1.28.1-1.fc38.noarch (not an OpenPGP signature)
495 koji-1.28.1-1.fc38.noarch (not an OpenPGP signature)
Despite the fc38 disttag, this is not the koji package from Fedora
rawhide, the real rawhide version is koji-1.30.1-2.fc38 and *that* is
signed with RSA/SHA256. What the heck?
Time to file a ticket someplace. Rel-eng, I suppose?
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
