The pattern matching allows me to do tests in projects like:
$ copr-dev create measure-aws-powerful-c7i.8xlarge --chroot fedora-rawhide-x86_64
But the instance type needs to be selected manually in pools.yaml.
This will recycle VMs more quickly, after 90s of idling. This is giving
their assigned users smaller changes to re-take it. This though should
not be a problem nowadays since copr-backend is pretty optimal and each
"task dispatching cycle" takes less than 30s. If users have multiple
tasks to process, these tasks should still be happily dispatched within
the time-frame.
Rocky was added in the Anitya GUI, but does not have a mapping, so links
are not created for them which point to their corresponding sources on
their git forge.
The large instances discussed here
https://github.com/fedora-copr/copr/issues/2241
have large RAM memory segments, and no default disks. So we don't pay
attention to have additional volumes explicitly just for swap.
Recently (possibly with the new python in fedora 38), the updates-sync
logic that updates the 'latest' link for epel-release rpms has started
replacing it everytime it runs. Since this is every minute, it sometimes
results in people getting odd perm denied errors when they try and fetch
it as it's being removed or updated.
The problem seems to be that the script looks for all
epel-release*noarch* packages under a release tree and then links to the
x86_64 one. With all the other epel branches, x86_64 was the last one it
saw with the file glob, so everything was fine.
For some reason on epel7 now, it's seeing them in the following order:
/pub/epel/7/ppc64/Packages/e/epel-release-7-11.noarch.rpm
/pub/epel/7/x86_64/Packages/e/epel-release-7-14.noarch.rpm
/pub/epel/7/ppc64le/Packages/e/epel-release-7-14.noarch.rpm
/pub/epel/7/aarch64/Packages/e/epel-release-7-12.noarch.rpm
This means it sees the 'aarch64' one last and since it's not = to the
x86_64 one, it replaces it. Luckily it's hard coded to use the x86_64
one so the link is always the same, it's just never equal to the one
it's checking against.
I am not sure why this is happening only on epel7, but this PR just
sorts all the path's so that x86_64 is always 'last' and should match
up.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
bodhi was using a small script to copy flatpak images from candidate
registry to registry. This was done because skopeo wasn't able to copy
multi-arch containers at the time. It has since gained the ability to do
that and we should stop using the temporary script to do this.
The script doesn't understand the new f39+ flatpaks hash passed to it so
it fails to push them.
This patch switches bodhi to use normal skopeo and pass it -a which
should tell it to copy all the arches, not just the one it's running on.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
