The Custom method should have `fedora-stable-x86_64` option

[praiskup]

The fedora-latest-x86_64 isn't optimal, the failure probability is relatively high, e.g., here:

Start: installing minimal buildroot with dnf5
Updating and loading repositories:
 updates                                100% |   1.5 KiB/s |   7.5 KiB |  00m05s
 fedora                                 100% |   5.4 MiB/s |  32.7 MiB |  00m06s
 Additional repo copr_packit_packit_sta 100% | 147.0   B/s |   1.3 KiB |  00m09s
>>> Status code: 404 for https://download.copr.fedorainfracloud.org/results/pack
>>> Status code: 404 for https://download.copr.fedorainfracloud.org/results/pack
>>> Status code: 404 for https://download.copr.fedorainfracloud.org/results/pack
>>> Status code: 404 for https://download.copr.fedorainfracloud.org/results/pack
>>> Librepo error: Cannot download repomd.xml: Cannot download repodata/repomd.xFailed to download metadata (baseurl: "https://download.copr.fedorainfracloud.org/results/packit/packit-stable/fedora-41-s390x/") for repository "copr_packit_packit_stable"
 Librepo error: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
WARNING: DNF5 command failed, retrying, attempt #2, sleeping 10s
...

[praiskup]

Wait, are we using s390x for source RPM builds? :-/ s390x is the most scarce resource.

[praiskup]

Nah, this is probably breaking all custom builds (including packit): https://copr.fedorainfracloud.org/coprs/g/mock/mock-pull-requests/build/8023082/

This is the issue for the broken mirrormanager: https://pagure.io/fedora-infrastructure/issue/12183

It is acceptable to have problems like that in Fedora in the early stages of the branched version, but it is not acceptable for Copr (we should use the stable default).

[praiskup]

https://github.com/fedora-copr/copr/blob/cbb058f472612bccc095aa865162e0656a439050/frontend/coprs_frontend/coprs/models.py#L1027-L1030 fedora-latest solution

[FrostyX]

Just FTR we want to use fedora-distro-aliases for this and we discussed caching. Fedora-distro-aliases currently implements caching to have a fallback when Bodhi is down but the cache doesn't provide any performance benefits. Even if a cache exists, we try to get fresh results from Bodhi.

I don't think we should change this behavior and always use cache if cache is available but instead try something like this on Copr side:

from coprs import cache
@cache.memoize(timeout=666)  # Maybe an hour? Maybe a day?

but we should first do some testing if @cache.memoize is shared for every thread, if it survives systemctl restart httpd, and so on.