F44 Change Proposal: golang1.26 [SystemWide]

Project Discussion Change Proposals
, ,
1

golang1.26

Wiki
Announcement

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.

Summary :open_book:

Update of Go (golang package) to the upcoming version 1.26 in Fedora 44.

Owner :open_book:

  • Name: [[User:alexsaezm| Alejandro SĂĄez MorollĂłn]]
  • Email: asm@redhat.com

Detailed Description :open_book:

Update of Go (golang package) to the upcoming version 1.26 in Fedora 44. Go 1.26 is expected to be released in [Go 1.26 Release Notes - The Go Programming Language February 2026]. A mass rebuild of all the dependent packages is required.

Feedback :open_book:

Not feedback yet.

Benefit to Fedora :open_book:

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.26 Release Notes - The Go Programming Language

Scope :open_book:

  • Proposal owners:
    Rebase the Golang package in Fedora 44 and help resolve any issues found during the rebuild.

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

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

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

  • Alignment with the Fedora Strategy:

Upgrade/compatibility impact :open_book:

No upgrade or compatibility impact.

Early Testing (Optional) :open_book:

Do you require ‘QA Blueprint’ support? N

How To Test :open_book:

  1. Install golang 1.26 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.26 should work as expected.

User Experience :open_book:

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

Dependencies :open_book: 

dnf repoquery -q  --releasever=rawhide --disablerepo='*' --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires 'golang'
dnf repoquery -q  --releasever=rawhide --disablerepo='*' --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires 'compiler(go-compiler)'
dnf 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.

Contingency Plan :open_book:

Documentation

https://tip.golang.org/doc/go1.26

Release Notes :open_book:

Last edited by @alking 2025-11-04T12:53:43Z

Last edited by @alking 2025-11-04T12:53:43Z

:e_mail: Email announcement: Making sure you're not a bot!

Last edited by @alking 2025-11-04T14:04:34Z

Last edited by @alking 2025-11-04T14:04:34Z

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

Please enable DWARF5!

4

This proposal is a bit old now and already approved. As we discussed in another thread, I cannot enable DWARF5 at all right now without breaking the whole ecosystem. If you truly need it, I can generate a COPR repository with it enabled.

5

Hi Álex. Sorry to bother with this. Indeed, I’ll build a repo with just go and dlv.
ps: what is a COPR repository?

6

COPR allows us to ship packages that, for some reason, are not suitable for the main repositories (things like this case, for example; it’s not a blank slate for non-free software). For example, the Go SIG has enabled a repository that follows whatever version is in Rawhide, so you can enable more recent versions of Go in “older” versions of Fedora.

I can create a repository and enable the DWARF5 support there if that helps you, and also build delve there. So if you enable that repository and install the versions from there, those two packages would have DWARF5. Hope it makes sense. Is that something that will help you?

7

I did not know about this! Very interesting. If it does not disrupt your work, this would be very welcome!

8

Hey @rafael2k, here is the DWARF5 COPR project. Basically, what you get by enabling it is the same version of Go from Rawhide but with DWARF5 enabled (only Go, not other packages). Future updates should be mostly automatic. I also enabled it myself:

Before:

$ go version
go version go1.25.7 X:nodwarf5 linux/amd64

After:

$ go version
go version go1.26.1 linux/amd64

Keep in mind that I don’t have a good way to deprecate COPR repositories, so when we can finally enable DWARF5 in the main repository, you should manually remove the repository. But you will probably see a missing repository message while doing a system update when that happens.