Re: Help understanding Fedora CI failure wrt RPM Sequoia
Hi all, https://gitlab.com/testing-farm/infrastructure/-/merge_requests/90/diffs That would be the reason. We would never think this would cause so much confusion, our bad :( As the original issue is gone, we have reverted this workaround and I hope it is resolved now. Best regards, /M On Thu, Nov 10, 2022 at 9:49 PM Kevin Fenzi wrote: > On Thu, Nov 10, 2022 at 11:39:27AM +0200, Panu Matilainen wrote: > > > > 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. > > Nothing should have updated the koji package. > > The last change was in october: > > Wed Oct 26 14:08:39 2022 koji-1.30.1-2.fc38 tagged into f38 by bodhi > [still active] > > In fact there's no such actual build: > > ➜ ~ koji list-history --build koji-1.28.1-1.fc38 > 2022-11-10 12:39:45,017 [ERROR] koji: GenericError: No such build: > 'koji-1.28.1-1.fc38' > > Very odd that ci would use a build that doesn't exist. (I guess it's a > scratch build it made itself?) > > kevin > ___ > 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 > -- Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252 Remote Czech Republic :: Red Hat Czech s.r.o ___ 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
Re: Help understanding Fedora CI failure wrt RPM Sequoia
On Thu, Nov 10, 2022 at 11:39:27AM +0200, Panu Matilainen wrote: > > 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. Nothing should have updated the koji package. The last change was in october: Wed Oct 26 14:08:39 2022 koji-1.30.1-2.fc38 tagged into f38 by bodhi [still active] In fact there's no such actual build: ➜ ~ koji list-history --build koji-1.28.1-1.fc38 2022-11-10 12:39:45,017 [ERROR] koji: GenericError: No such build: 'koji-1.28.1-1.fc38' Very odd that ci would use a build that doesn't exist. (I guess it's a scratch build it made itself?) kevin signature.asc Description: PGP signature ___ 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
Re: Help understanding Fedora CI failure wrt RPM Sequoia
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
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?
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 -- 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
Re: Help understanding Fedora CI failure wrt RPM Sequoia
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 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?
Filed https://pagure.io/fedora-ci/general/issue/371
- 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
Re: Help understanding Fedora CI failure wrt RPM Sequoia
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@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
Re: Help understanding Fedora CI failure wrt RPM Sequoia
On 08. 11. 22 20: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"...
See also https://src.fedoraproject.org/rpms/rpm/pull-request/29
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Re: Help understanding Fedora CI failure wrt RPM Sequoia
On Tue Nov 8, 2022 at 12:13 +0200, 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. > > - Panu - I did some debugging in [1]. See my comment in that PR for more information. [1]: https://src.fedoraproject.org/rpms/rpm/pull-request/29 -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ 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
Re: Help understanding Fedora CI failure wrt RPM Sequoia
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"...
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
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
Re: Help understanding Fedora CI failure wrt RPM Sequoia
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... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ 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
Re: Help understanding Fedora CI failure wrt RPM Sequoia
On Tue, 2022-11-08 at 13:32 +0200, Panu Matilainen wrote:
> 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.
All that task means is "ensure all packages are updated". It basically
means ansible will run 'dnf -y update' and expect it to succeed.
There should be logs *somewhere* showing what happened when it did
that.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
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
Re: Help understanding Fedora CI failure wrt RPM Sequoia
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
Re: Help understanding Fedora CI failure wrt RPM Sequoia
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.
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
Help understanding Fedora CI failure wrt RPM Sequoia
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. - 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
