* Alejandro Saez Morollon: > On Thu, Nov 6, 2025 at 4:33 PM Brad Smith <[email protected]> wrote: > >> I recently ran across a problem when revising the Kubernetes 1.34 rpm >> spec file. I was testing the revised rpms in a VM by creating a >> cluster using kubeadm. >> >> The rpms in the Fedora repositories were built with go 1.24 and worked >> as expected. The revised rpms were built with go 1.25 and kubeadm >> failed with an unexpected error (see >> https://github.com/kubernetes/kubernetes/issues/135013 for error >> details if interested). >> >> In the discussion with the Kubernetes team they determined that yes >> there is a bug in the code with go 1.25 (and go 1.24.8+) and that a >> fix is in place and will be included in the next release (11 Nov more >> or less). But they were also specific that they expect distributions >> to build Kubernetes with the version of Go they explicitly build with >> - in this case Kubernetes 1.34 is built with go 1.24. Their makefile >> is structured to download the correct version of Go if not present on >> the build machine. They cannot guarantee that Kubernetes built with a >> newer version (at the minor level) will function correctly. To >> paraphrase their comment - there is a tight coupling between a >> Kubernetes version and a Go version. >> >> Fedora rawhide (f44) and F43 now use Go 1.25 which means I have to >> consider whether or not to continue releasing Kubernetes updates for >> these Fedora releases. Past record suggests that this is a rare >> problem but as noted above it can occur. > > Let me excuse myself first because of the delayed answer. > > This is a good counterargument example. So having a compat package > would have made your life easier, right? Because you could have > pointed to golang1.24 and called it a day.
I think what would have been needed is a golang1.24.7 compat package—the bug is present in 1.24.8 and later per Brad's message. Per the upstream issue, one has to use exactly the specified Go minor version. Not sure if this is something that Fedora wants to support in general. (There was an approved change proposal to adopt upstream toolchain choices, and even though the example quoted where of the form, “use this specific compiler binary”, that was not the Fedora proposal.) Thanks, Florian -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
