So... It looks like somehow that link is getting updated every minute or two. ;(

I suspect possibly changes made for epel10?

CC: @carlwgeorge @dherrera

# date; stat /srv/pub/epel/epel-next-release-latest-9.noarch.rpm 
Mon Dec  9 06:04:25 PM UTC 2024
  File: /srv/pub/epel/epel-next-release-latest-9.noarch.rpm -> 9/Everything/x86_64/Packages/e/epel-next-release-9-8.el9.noarch.rpm
  Size: 67              Blocks: 8          IO Block: 65536  symbolic link
Device: 2eh/46d Inode: 341         Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (  263/ UNKNOWN)   Gid: (  263/ UNKNOWN)
Context: system_u:object_r:nfs_t:s0
Access: 2024-12-09 18:03:03.631498000 +0000
Modify: 2024-12-09 18:03:03.631498000 +0000
Change: 2024-12-09 18:03:03.631498000 +0000
 Birth: -

I'm looking into it, but it most likely have to do with this method

https://pagure.io/fedora-infra/ansible/blob/main/f/roles/bodhi2/backend/files/new-updates-sync#_465-505

Here are all of the EPEL 10 changes we've made to that section of the code.

• bodhi / backend / new_updates_sync: don't try and link epel-release for 10 yet
• Update new-updates-sync to not skip EPEL 10
• bodhi/backend: use major version to construct EPEL latest link

I was looking into it, and It doesn't have to do with those changes :)

https://pagure.io/fedora-infra/ansible/blob/main/f/roles/bodhi2/backend/files/new-updates-sync#_455-458

This method is supposed to check for the relative and absolute paths of the epel-next-release-latest rpm on the x80_64 folder, but because of the way it's being checked, the absolute path can end up being from any architecture. This is what it's being checked later to see if the current symlink is pointing to the correct path.

Sent a PR that should fix this problem

https://pagure.io/fedora-infra/ansible/pull-request/2405

Good find, that does look to be the problem.

Yeah, great work.

I'm pushing the pr now.

I hope this fixes the issue? If you are still seeing it, please re-open.

Yeah, we are no more seeing the problems. Thanks for the fix!