On 11/8/22 13:05, Miro Hrončok wrote:
On 08. 11. 22 11:13, Panu Matilainen wrote:
Hey,

Thought I'd try to get on with the times and do the Sequoia change via a PR instead of just pushing as we've traditionally done. So far so good, but it throws up an error which I have no idea how to debug:

https://artifacts.dev.testing-farm.io/700d486d-d409-44fe-b7c3-01634243558e/

 > Unknown Error occured: An rpm exception occurred: package not installed

Okay, something failed, and it appears to be related to this very change as the tests pass with a "no-op" PR. And in that case, a good thing it got caught. But how on earth to debug this? I don't see anything even remotely relevant in the accompanying logs, nor did I find any obvious way to run this stuff locally.

Help, Obi-Wan KenoCI.

I am far from being a jeCI master,

but considering the tests there were added by me, for pyproject-rpm-macros, I decided to have a look.

The STI tests are at https://src.fedoraproject.org/rpms/rpm/blob/rawhide/f/tests/tests.yml

They more or less start with:

   tasks:
     - dnf:
         name: "*"
         state: latest

And the logs you link to say:

  TASK [dnf] *********************************************************************
   fatal: [sut]: FAILED! => {
       "changed": false,
       "failures": [],
       "rc": 1,
       "results": []
   }

   MSG:

   Unknown Error occured: An rpm exception occurred: package not installed

This means the problem you hit is that ansible is unable to run the DNF task.

Yep, that much I understood: something dnf related is failing. And that something looks like a situation where dnf thinks a package should be installed but isn't.

Now, such a scenario could occur in this very context if there are packages with SHA1 signatures involved: a previously installed package would seem uninstalled as the header just became unaccessible due to the bad signature. Or other similar scenarios revolving around this. But what package is that?

I know how to reproduce the actual tests locally without ansible, but that would avoid this problem. I suggest not trying to reproduce the tests, but reproducing the ansible failure in isolation. My ansible skills are limited, I knwo how to edit the YAML, but I have no idea how to actually try this out.


Okay, a good point - this quite obviously is *not* related to the python %generate_requires tests, so trying to reproduce that in itself is not useful.

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.

Thanks for trying to help.

        - Panu -
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to