F45 Change Proposal: Golang 1.27 (system-wide)

Project Discussion Change Proposals
,
1

Golang 1.27

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Update of Go (golang package) to the upcoming version 1.27 in Fedora 45.

:link: Owner

:link: Current status

  • Targeted release: Fedora Linux 45
  • Last updated: 2026-05-13
  • [ Announced]
  • [ Discussion thread]
  • FESCo issue:
  • Tracker bug:
  • Release notes tracker:

:link: Detailed Description

Update of Go (golang package) to the upcoming version 1.27 in Fedora 45. Go 1.27 is expected to be released in August 2026. A mass rebuild of all the dependent packages is required.

:link: Feedback

No feedback yet.

:link: Benefit to Fedora

Fedora users will receive the most current and recent Go release. Being close to upstream allows us to avoid security issues and provide more updated features. Consequently, Fedora will provide a reliable development platform for the Go language and projects written in it.

For a complete list of changes, see upstream change notes at Go 1.27 Release Notes - The Go Programming Language

:link: Scope

  • Proposal owners:

Rebase the Golang package in Fedora 45 and help resolve any issues found during the rebuild.

  • Other developers:

Fix potential issues with the help of the Golang package maintainers.

Rebuild of dependent packages as part of planned mass-rebuild.

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

It helps maintain the quality of the project, even though it doesn’t align directly with the current objectives.

:link: Upgrade/compatibility impact

No upgrade or compatibility impact.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? N

:link: How To Test

  1. Install golang 1.27 from rawhide and use it to build your application(s)/package(s).
  2. Perform a scratch build against rawhide.
  3. Your application/package built using golang 1.27 should work as expected.

:link: User Experience

Users will have a newer version of Go, with new features described in the release notes and security fixes.

:link: Dependencies

dnf4 repoquery -q --releasever=rawhide --disablerepo=‘’ --qf=‘%{name}’ --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires ‘golang’ dnf4 repoquery -q --releasever=rawhide --disablerepo='’ --qf=‘%{name}’ --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires ‘compiler(go-compiler)’ dnf4 repoquery -q --releasever=rawhide --disablerepo=‘*’ --qf=‘%{name}’ --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires ‘go-rpm-macros’

Omitted due to the number of packages listed: ~900.

:link: Contingency Plan

  • Contingency mechanism: Revert to Go 1.26.X if significant issues are discovered
  • Contingency deadline: Beta freeze
  • Blocks release? No

:link: Documentation

:link: Release Notes

Last edited by @amoloney 2026-05-27T09:23:46Z

Last edited by @amoloney 2026-05-27T09:23:46Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

Definitely in favor, but out of curiosity, why the dnf4 repoquerys? dnf5 should be fine these days as far as I know?

4

Because I usually default to dnf4 for some actions instead of learning that dnf5 has that command. So shame on me for not updating myself.

For example, I still have plenty of scripts with dnf4 whatprovides because I never investigated how to do it in dnf5 :person_facepalming:

5

This change proposal has now been submitted to FESCo with ticket #3614 for voting.

To find out more, please visit our Changes Policy documentation.

6

I’m all for it, but I have a question. Currently the golang package is built with GOEXPERIMENT=nodwarf5 because of the incompatibility between dwarf5 and debugedit (see https://sourceware.org/bugzilla/show_bug.cgi?id=33204). What are the chances that this limitation will be resolved in debugedit and eventually the golang package in Fedora 45 will be built without GOEXPERIMENT=nodwarf5?

7

To be honest, zero chances. Unless debugedit fixes it on their side, my PR for Go with the fix is not going anywhere soon (mostly because I didn’t have time to address upstream concerns). The solution for Go users is to use this Go SIG COPR repository.

Edit: Even though a solution probably won’t appear in this release, I will work on this next week and try to figure out what is the most viable solution because I don’t want to keep having that flag (and it can go away at any moment, so it’s not a reliable way to have it).