I’ve not yet looked into it as I seem to have too many pre-FF fixes to make.
But out of experience (2 out of 3 of last cycles late glibc update) this quite likely is glibc making changes which syscalls libc functions eventually issue and that really breaks chrony which by default runs sandboxed with a seccomp allow-list.
Thereby this usually is real breakage (the service isn’t usable anymore) and thereby needs to be fixed before allowing libc to migrate.
It usually comes down to throw things in a VM to see what it breaks on, extending the list, discussing upstream for acceptance and then uploading it as Delta to our version. Unfortunately most of the time these changes are ppc64 or armhf which are harder to come by (emulation slow, systemc rare).
I’ll put it on my todo-list, but as I said it is a long list these days. If anyone else gets to work on it please let me know of any progress you made.
update
Debugging indeed show new syscalls as assumed, gladly this time the fix already is merged upstream and I can prep an upload based on that.
Spawned this bug to track it
update 2
Test works now, test is green (also triggered gnutls28 vs the new chrony which hit the same issue), now chrony is blocked by glibc as one would expect. It is already striked throughin the list above - so this is thereby complete.