Dennis Gilmore comment seems relevant to me :

koji uses very simple logic in parsing mock return codes
https://pagure.io/koji/blob/master/f/builder/kojid#_544 it looks like
mock has started using different return codes and koji will need to
learn them all

Yes. However, is the new exit code expected or a bug in mock?

I believe, that our code is outdated - it is there from 2008 and counts only with exitcode '1'. I think, that it should be os.WEXITSTATUS(rv) > 0 instead of current os.WEXITSTATUS(rv) == 1 which leads to 'build.log'.

About parsing all codes - it could have some value to display basic info about 21 error codes of mock - on the other hand almost in all cases you would like to see mock's traceback, so maybe just saying it is in build.log is enough. Opinions?

What code would lead to root.log then?

Hmm, we need @msuchy anyway :-)

The exit codes are documented here: https://github.com/rpm-software-management/mock/wiki#exit-codes Issues during rpmbuild (i.e. tracked in build.log) are usually exit code 10.

@msuchy So, you think, that #1682 behaviour is better "heuristic"?

Commit 8b3d3ad fixes this issue

Commit 3f64a48 fixes this issue

Looks like this is still broken. Here's a build which clearly fails in build.log (due to a missing binary):

https://koji.fedoraproject.org/koji/taskinfo?taskID=39774944

Koji thinks the failure is in root.log.

Problem is, that mock returns return code 1 as a fallback. So, such error can be either in root or build log. Maybe I can add third option (10 -> build.log, 1-> build.log or root.log, else root.log).

Problem is, that mock returns return code 1 as a fallback. So, such error can be either in root or build log. Maybe I can add third option (10 -> build.log, 1-> build.log or root.log, else root.log).

I agree, return 1 is build.log

I've created #1899 for 1.21 (as this one is already part of 1.19)

This still seems to be happening (see https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/23GPKHVNN5VEXQ273MHEUYEQCJ4CHOB6/) -- @adamwill suspects one of the commits is not deployed yet.

Is this issue still the right place to track it, or is this more for Koji-the-software, and I should open a new issue somewhere? Thanks!

Also curious if we can improve mock to more reliably report build.log errors.

@salimma https://pagure.io/fedora-infrastructure/issues , would be where to file issues relating to our Koji deployments. The second commit is in Koji 1.21.0 which is built and an update has gone out, but I can't tell if we're running that version, because the web UI doesn't say and I don't have enough privileges to log into the server itself and see.

If we're running 1.21.0 and still seeing the wrong message, it seems like an upstream bug. If we're just not running 1.21.0 yet, there's nothing else to do here and we need an infra ticket.

@adamwill filed a ticket asking infra to check, so it's either a quick action of "yep, we're on 1.21.0" or we can use that ticket for requesting the upgrade

https://pagure.io/fedora-infrastructure/issue/8936

nirik confirmed we have 1.20.1, and we'll get the fix with the DC move in June.