More: 1018185, 1018192, 1018202, 1018212, 1018213, 1018220, 1018221, 1018224

hmpfs, yes

When a build fails like this, i.e.

• build log looks that it succeeded
• there is a file success touched in the build result directory
• and there are RPMs in the results directory

and yet, it is marked as failed, there is usually an issue with signing the package. IDK whether this is also the case.

Another one, just in case it helps with debugging: 1028091.

Snippet from .

So those failures are related to the frontend outages (still occurring IO/cpu problems).

IOW, backend failed to retrieve info about the auto-createrepo flag (which itself can be optimized out and be part of the job info).

Not only failed, we have one running build chroot:

In this build, which has already signed packages.

Thinking about this -> it doesn't make sense that backend gives up with posting the build status to frontend; it simply should continue reporting indefinitely, till the frontend becomes available.

it simply should continue reporting indefinitely, till the frontend becomes available.

That sounds like a good idea.

https://pagure.io/copr/copr/pull-request/1021

Commit 678f797 fixes this issue

This is still happening. See, e.g., https://copr.fedorainfracloud.org/coprs/iucar/cran/build/1149353/

Because of the outage window, which was too long today, sorry for that.
Please reopen if you see similar problems again since now.