Howdy, sorry for the bad experience, I am looking at this.

https://src.fedoraproject.org/rpms/python-virtualenv/pull-request/136
https://src.fedoraproject.org/rpms/python-virtualenv/pull-request/137

The EPEL updates with Python 3.13 went stable 9 hours ago, but the CI tests don't see python3.13-devel.

Another example was https://bodhi.fedoraproject.org/updates/FEDORA-2025-bc6d99cf7e

Hmm, considering that these runner are likely behind a mirror that would not be updated, what tools do we have to force it to use the latest state of the rawhide? Afaik enabling the bodhi repo has a similar issue for the mirror propagation.

Also to clarify in the cases that it fails, the dependency that it is trying to pull is not one that is in the koji-build side-tag right?

The dependency that it is trying to pull is in the Koji build repo.

One thing that occurred to me is that this repeatedly happens on Rawhide. Are you using https://kojipkgs.fedoraproject.org/repos/rawhide/latest/ or https://kojipkgs.fedoraproject.org/repos/f44-build/latest/ ? I found out (and it was confirmed by infra/releng) that the rawhide one is regenerated less often than the fXX one.

We are in transition to refactor the whole logic, but currently the steps done are described in build installation which consist of creating a repo from the downloaded artifacts and installing all artifacts in the koji build(s). It does not do anything else to the repos that was not in the rawhide container. The koji download step goes through the koji download-task if that makes any difference, and the taskID is extracted from Jenkins from the rabbitMQ message.

There are other steps like the (pre|post)_artifact_installation, but I do not see a step in there that involves the enabling/disabling of koji/bodhi repos, although there is the /etc/yum.repos.d/tag-repository.repo that was reported to interfere often (which is a thing that we are trying to get rid of in the refactor).