Cirrus: remove centos9 build job

[lsm5]

Packit ensures c9s buildability, so there's no need for this job.

[lsm5]

@cevich @Luap99 @mheon PTAL

[Luap99]

In principle yes that is the right thing to do.

However merge protection is not setup for any packit task, mainly because packit tasks are failing to often with random failures (this results in us maintainers ignoring them).

Given nobdy looks after quay.io/libpod/centos9rust image either I am still in favor of merging this so LGTM

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lsm5, Luap99

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Luap99,lsm5]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[lsm5]

i've begun talks with the go maintainers for centos stream about adding reverse dependency tests on golang rpms before they enter centos stream build environments. So, we should be able to block on packit tasks sometime soon.

[Luap99]

I have not looked at enough to errors to tell but I don't see how blocking golang rpms is helping us here.
There are packit/tmt/whatever flakes in this pipeline, i.e. #1016 (comment), random dnf install failures at runtime, etc...

And our tests contain flakes too of course so the total number of flakes perceived by me looks high. Of course I have no tool to measure the actual numbers.

[lsm5]

I have not looked at enough to errors to tell but I don't see how blocking golang rpms is helping us here. There are packit/tmt/whatever flakes in this pipeline, i.e. #1016 (comment), random dnf install failures at runtime, etc...

uh ya, sorry i meant along with golang, I have plans to check with rust maintainers as well

RE: flakes on that PR, I'll report those to packit.

RE: dnf install failures, please let me know next time you see them. Quite likely something can be done to fix issues in COPR or how we install packages.

[Luap99]

RE: dnf install failures, please let me know next time you see them

There are permanently broken on aardvark-dns rawhide currently as an example, https://artifacts.dev.testing-farm.io/d4eac9f2-f05c-4585-8324-0e29a55ed479/
I assume you are already aware of this.
Note I am overall in favor to expand packit/tmt test on aardvark/netavark repos but we cannot setup merge protection for these tasks if we have to to overwrite them to often. And without merge protection we may merge broken changes as most of us are used to ignore the packit/tmt jobs entirely.

[lsm5]

RE: dnf install failures, please let me know next time you see them

There are permanently broken on aardvark-dns rawhide currently as an example, https://artifacts.dev.testing-farm.io/d4eac9f2-f05c-4585-8324-0e29a55ed479/ I assume you are already aware of this.

Yes, I've learned a few things since the last change to aardvark-dns PR. Things have been fixed in container-selinux to account for this and I'll be replicating that to aardvark-dns.

Note I am overall in favor to expand packit/tmt test on aardvark/netavark repos but we cannot setup merge protection for these tasks if we have to to overwrite them to often. And without merge protection we may merge broken changes as most of us are used to ignore the packit/tmt jobs entirely.

About merge protection, we'll have to start somewhere. I'll start on container-selinux right away, and soon as we have revdep testing on golang and rust, we can start blocking on build jobs (and later on test jobs) on other repos.

[Luap99]

@mheon @baude PTAL

[mheon]

I am LGTM on this

[Luap99]

was removed in #1098