This appears to only happen for multi-arch image tasks.

The createImage subtask doesn't even use mock, but it abuses the BuildRoot class in a way that causes the mock config to be logged (and for that matter for an empty buildroot entry to be created). When an image task has multiple createImage subtasks, there are multiple mock_config.log files. Unfortunately, the image import code doesn't handle this well.

Possible fix in #4232

I applied this in staging...

a scratch image build:
worked: https://koji.stg.fedoraproject.org/koji/taskinfo?taskID=130059530
a real image build:
failed with a weird errror: https://koji.stg.fedoraproject.org/koji/taskinfo?taskID=130060426

I think that error may be unrelated, but not sure.

The last does indeed look unrelated. I can't see the full trace, but there is indeed no such rpm in koji stage (it does exist in prod). The image in question is from prod, so not surprising that the result includes prod rpms.

The image import code has had get_rpm(an_rpm, strict=True) since 2009, so I don't think this is a regression.

This error does at least come after the loop where the previous error was happening ;)

Yeah, I ran that build in stg, but with the last rawhide repos from pungi, so it was prod rpms... so yeah, that explains it. ;)

Sorry for the noise there...

I am going to see about pushing this to prod because we really would like to have that image for release...

After upgrading to koji-1.35.2, it broke the image-build of a multi-arch docker-base, with the following error:

FAILED: GenericError: Error importing build log. /koji/packages/alma9-docker-base/20250227/1/data/logs/image/mock_config.log already exists.

The same command sometimes failed with the error: FAILED: GenericError: rmtree process was killed by signal 6, but we are not sure if it is related with this issue.
Applying the patch that fixes this issue, worked for us :)

Koji command:

koji image-build alma9-docker-base `date "+%Y%m%d"` alma9-image-9x \
    http://linuxsoft.cern.ch/cern/alma/9/BaseOS/\$arch/os/ x86_64 aarch64 \
    --ksurl=git+ssh://git@gitlab.cern.ch:7999/linuxsupport/alma9-base#master \
    --kickstart=alma9-base-docker.ks --ksversion=RHEL8 --distro=RHEL-9.0 --format=docker \
    --factory-parameter=dockerversion 1.10.1 \
    --factory-parameter=docker_env '["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"]' \
    --factory-parameter=docker_cmd '["/bin/bash"]' \
    --factory-parameter=generate_icicle False \
    --wait --scratch

Yes, looks like the same issue

The issue was impossible to test due to the lack of an instance with an architecture other than x86_64. Therefore, it was reclassified to testing_basic. It is well covered by unit tests and has already been tested by the reporter of the issue.

Commit 91ec3d58 fixes this issue

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/4231

Please continue any further discussion there.