Discussed in today's meeting - this issue is affecting more than toolbox builds and there's been recent discussion about workarounds. We'll wait and see how things pan out.

I don't think waiting is going to work here.

The problem here is the well-known clone3 syscall issue. Basically there is a new syscall that glibc is using, but which is prohibited by docker and podman seccomp policies. If the syscall is prohibited, glibc would usually fall back to the older clone syscall, but in this case the wrong error code is returned and so glibc does not do its normal fallback. The solution is to run newer versions of docker and/or podman on the systems that are experiencing these problems.

If we really want this fixed, we need to nominate it as a special release blocker to force infrastructure upgrades. There's not really anything that normal developers can do about infrastructure. To the extent that there is a desire to keep certain infrastructure components running RHEL 7, then we either need to rethink that, or else update RHEL 7.

The infrastructure ticket was closed as fixed 3 days ago. I see successful toolbox builds in Koji, but nothing for F35.

Can someone confirm whether it's possible to build F35+ toolbox images, now?

Both fedora-toolbox:35 and fedora-toolbox:36 images are now in the stable registry since last week.