On 11/9/22 11:12, Panu Matilainen wrote:
On 11/9/22 10:08, Panu Matilainen wrote: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 roughidea 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?Filed https://pagure.io/fedora-ci/general/issue/371
So, overnight somebody updated the koji package in https://kojipkgs.fedoraproject.org/repos/rawhide/ to the current unsigned rawhide build, which makes the issue go away.
Thanks to whoever did that.
And now off to build the thing while the lights are green...
- 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://pagure.io/fedora-infrastructure/new_issue
