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. best regards Brad On Thu, Nov 6, 2025 at 5:29 AM Alejandro Sáez Morollón <[email protected]> wrote: > > On 2025-11-06 12:11, Fabio Valentini wrote: > > On Wed, Nov 5, 2025 at 8:30 AM Alejandro Sáez Morollón <[email protected]> > > wrote: > >> > > > > (snip) > > > > Thank you for working on this! > > > >> TL;DR: Yes, they would have upgrades, but we might only have 2~3 compat > >> packages at a given time, and I, personally, think it adds more complexity. > > > > I agree, this seems to just be a complicated middle ground between the > > current status quo (major Go update pushed to stable branch) and fully > > versioned packages, with the downsides of both, but with the > > advantages of neither. > > > > And while I can see the argument that pushing major version updates > > for Go to stable branches can cause unintended breakage and churn, I > > don't think this would be a big problem in practice. And I assume that > > *if* a change to the update cycle for golang like this were > > implemented, the update would still land in rawhide *first*, then sit > > there for a while (weeks? months?) until all problems have been > > resolved, and *only then* merged to stable branches? > > > > Fabio > > That's right. Maybe it was not clear in my initial mail, but I am not > trying to remove in any way the workflow. Every new major release would > land on Rawhide first, build there, and then move into the other > releases. Similar to what we have right now but targeting more branches. > > Also, I intend to use mass-prebuild [0] before even pushing to Rawhide. > It's something that I should do no matter the outcome of the proposal, > as I hit/created last-minute issues in the previous two Fedora releases. > I played with the tool recently, and I really like it. > > As far as I know, we can't run it as part of the CI, but the state of > the packages will appear in COPR and I can always link it to the PRs for > everyone to see. > > [0] https://packages.fedoraproject.org/pkgs/mass-prebuild/mass-prebuild/ > > -- > _______________________________________________ > 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 -- _______________________________________________ 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
