Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1280346 > unrolled thread

Bug#1126733: transition: golang-1.26

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1126733: transition: golang-1.26 "Dr. Tobias Quathamer" <toddy@debian.org> - 2026-01-31 22:40 +0100
    Bug#1126733: transition: golang-1.26 Sebastian Ramacher <sramacher@debian.org> - 2026-02-03 10:30 +0100
      Bug#1126733: transition: golang-1.26 "Dr. Tobias Quathamer" <toddy@debian.org> - 2026-02-03 14:50 +0100
    Bug#1126733: Results of a rebuild with golang-1.26 "Dr. Tobias Quathamer" <toddy@debian.org> - 2026-02-05 09:40 +0100
      Bug#1126733: Current status of golang-1.26 "Dr. Tobias Quathamer" <toddy@debian.org> - 2026-02-18 20:00 +0100
        Bug#961916: Bug#1126733: Current status of golang-1.26 Tianon Gravi <tianon@debian.org> - 2026-02-19 07:20 +0100
          Bug#1123912: Bug#1126733: Current status of golang-1.26 Tianon Gravi <tianon@debian.org> - 2026-02-19 08:00 +0100
          Bug#961916: Bug#1126733: Current status of golang-1.26 "Dr. Tobias Quathamer" <toddy@debian.org> - 2026-02-19 10:50 +0100
        Bug#1126733: Current status of golang-1.26 Sebastian Ramacher <sramacher@debian.org> - 2026-03-01 20:00 +0100
          Bug#1126733: Current status of golang-1.26 "Dr. Tobias Quathamer" <toddy@debian.org> - 2026-03-21 15:20 +0100
            Bug#1126733: Current status of golang-1.26 Sebastian Ramacher <sramacher@debian.org> - 2026-03-23 22:40 +0100

#1280346 — Bug#1126733: transition: golang-1.26

[Multipart message — attachments visible in raw view] — view raw

Package: release.debian.org
User: release.debian.org@packages.debian.org
Usertags: transition
X-Debbugs-Cc: toddy@debian.org
Severity: normal

Dear release team,

as you're probably aware, the default golang compiler version for Debian 
is determined with the golang-defaults package. Currently, the 
golang-defaults package points to golang 1.24.

Upstream has released golang-1.25 in August 2025, and the next version 
1.26 will most probably be released in about two weeks.

We'd like to switch the default golang version to the latest upstream 
(probably to 1.26, after it has been released).

In https://bugs.debian.org/1116589, Tianon and I had a short 
conversation about how to do this. Tianon said that he thinks this needs 
a transition, so I'm reaching out to you.

However, I'm a bit lost as to how a Ben file could be written. From my 
quick search with grep-dctrl, it seems that only the golang-compiler 
packages need to be rebuilt:

$ grep-dctrl -F Depends: "golang-go " -s Package Packages
Package: golang
Package: golang-any
Package: golang-doc

$ grep-dctrl -F Depends: "golang-1" -s Package Packages
Package: golang-1.24
Package: golang-1.24-go
Package: golang-1.25
Package: golang-1.25-go
Package: golang
Package: golang-doc
Package: golang-go
Package: golang-src

Which does make sense, because the golang-*dev packages are constructed 
to include the source files, there is no binary library compiled.


So, it would be great if you could give your perspective on this -- do 
we need a transition for a new golang compiler? If yes, how could we 
track the progress?

Regards,
Tobias

[toc] | [next] | [standalone]

#1280578

On 2026-01-31 22:37:21 +0100, Dr. Tobias Quathamer wrote:
> Package: release.debian.org
> User: release.debian.org@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: toddy@debian.org
> Severity: normal
> 
> Dear release team,
> 
> as you're probably aware, the default golang compiler version for Debian is
> determined with the golang-defaults package. Currently, the golang-defaults
> package points to golang 1.24.
> 
> Upstream has released golang-1.25 in August 2025, and the next version 1.26
> will most probably be released in about two weeks.
> 
> We'd like to switch the default golang version to the latest upstream
> (probably to 1.26, after it has been released).
> 
> In https://bugs.debian.org/1116589, Tianon and I had a short conversation
> about how to do this. Tianon said that he thinks this needs a transition, so
> I'm reaching out to you.
> 
> However, I'm a bit lost as to how a Ben file could be written. From my quick
> search with grep-dctrl, it seems that only the golang-compiler packages need
> to be rebuilt:
> 
> $ grep-dctrl -F Depends: "golang-go " -s Package Packages
> Package: golang
> Package: golang-any
> Package: golang-doc
> 
> $ grep-dctrl -F Depends: "golang-1" -s Package Packages
> Package: golang-1.24
> Package: golang-1.24-go
> Package: golang-1.25
> Package: golang-1.25-go
> Package: golang
> Package: golang-doc
> Package: golang-go
> Package: golang-src
> 
> Which does make sense, because the golang-*dev packages are constructed to
> include the source files, there is no binary library compiled.
> 
> 
> So, it would be great if you could give your perspective on this -- do we
> need a transition for a new golang compiler? If yes, how could we track the
> progress?

We do not need a transition for the switch to a new golang version as we
do not need any rebuilds. The reverse dependencies will get rebuilt
during one of the "outdated Built-Using" rebuild campaigns. However,
we'd appreciate a test rebuild of the golang ecosystem before switching
to the new version so that we have an idea of the impact on the archive.
In that sense we appreciate coordination with us before switching the
default in unstable.

Cheers
-- 
Sebastian Ramacher

[toc] | [prev] | [next] | [standalone]

#1280604

[Multipart message — attachments visible in raw view] — view raw

Am 03.02.26 um 10:22 schrieb Sebastian Ramacher:
> We do not need a transition for the switch to a new golang version as we
> do not need any rebuilds. The reverse dependencies will get rebuilt
> during one of the "outdated Built-Using" rebuild campaigns.

Dear Sebastian,

that's what I thought, thanks for confirming.

 > However, we'd appreciate a test rebuild of the golang ecosystem
 > before switching to the new version so that we have an idea of the
 > impact on the archive. In that sense we appreciate coordination with
 > us before switching the default in unstable.

Right, I'll see how I can do this. I've just written to Lucas Nussbaum 
and asked if he could help with this.

Regards,
Tobias

[toc] | [prev] | [next] | [standalone]

#1280816 — Bug#1126733: Results of a rebuild with golang-1.26

[Multipart message — attachments visible in raw view] — view raw

Dear release team,

I've had great help from Santiago Vila, who has been kind enough to run 
a rebuild of the golang-* packages with golang-1.26-rc2.

The list of packages to include in the rebuild has been generated with 
this command:

$ build-rdeps --distribution unstable --only-main golang-go

This resulted in 2772 packages.

- 2699 packages still build fine with golang-1.26-rc2
- 73 packages fail

Please note that this list is still a preliminary report, I haven't 
checked yet if some of those 73 packages already FTBFS with the current 
golang-1.24 compiler.

Regards,
Tobias

[toc] | [prev] | [next] | [standalone]

#1282667 — Bug#1126733: Current status of golang-1.26

[Multipart message — attachments visible in raw view] — view raw

Dear release team,

golang-1.26 has been released and is already available in unstable (and
hopefully also in testing in a few hours).

About two weeks ago, I've written to you that there are 73 packages
which FTBFS during a rebuild of 2772 golang packages.

Out of those 73 packages, 8 were already known to FTBFS with the current
golang-1.24 compiler, leaving 65 new FTBFS bugs.

I've already fixed some issues in other packages, so this is the current
status:

- 2772 packages tested
- 21 new FTBFS bugs

I'm confident that we can handle those remaining build failures within
the golang package team.

So, if you don't have any objections, I plan to switch the default
golang compiler to 1.26 in the next few days.

Thoughts?

Regards,
Tobias

[toc] | [prev] | [next] | [standalone]

#1282705 — Bug#961916: Bug#1126733: Current status of golang-1.26

On Wed, 18 Feb 2026 at 10:59, Dr. Tobias Quathamer <toddy@debian.org> wrote:
> So, if you don't have any objections, I plan to switch the default
> golang compiler to 1.26 in the next few days.

It's a tiny bit tangential, so apologies for that, but I think it
would probably be prudent to finally do something about gccgo too,
while we're opening the hood on src:golang-defaults.

For a long time now, gccgo has been stuck at an implementation of Go
1.18, but even then, it's only a *partial* implementation of 1.18
(notably missing generics).

As noted and discussed in the CC'd https://bugs.debian.org/961916,
bin:gccgo-go's version is misleading at best and actively harmful at
worst, because it *looks* like it's 1.24, and this is where I think
the overlap with the proposal to update to 1.26 appears - that number
drifts even further from any truth.

In ideating on solutions, I was thinking about doing something really
goofy, like having bin:gccgo-go have a Version: that's 1.18 or
something, but that ship has sailed (we can't downgrade in the
archive), and it would be really poor behavior for one source package
to do that anyhow.

So concretely, what I'd propose for src:golang-defaults 1.26+ is that
we remove all traces of gccgo entirely instead.  This is somewhat
disruptive, but I don't think it's unreasonable.  Every interesting
architecture is currently supported by upstream golang-go, gccgo
hasn't been a suitable GOROOT_BOOTSTRAP for Go itself for several
versions now, and gccgo is a very outdated implementation.  On top of
all that, I strongly doubt there are many (if any) meaningful Go
packages left in the archive that really successfully build with
gccgo.

I am going to work on an even more concrete MR for review after
sending this email. 🙇

♥,
- Tianon

[toc] | [prev] | [next] | [standalone]

#1282709 — Bug#1123912: Bug#1126733: Current status of golang-1.26

On Wed, 18 Feb 2026 at 22:13, Tianon Gravi <tianon@debian.org> wrote:
> On Wed, 18 Feb 2026 at 10:59, Dr. Tobias Quathamer <toddy@debian.org> wrote:
> > So, if you don't have any objections, I plan to switch the default
> > golang compiler to 1.26 in the next few days.
>
> It's a tiny bit tangential, so apologies for that, but I think it
> would probably be prudent to finally do something about gccgo too,
> while we're opening the hood on src:golang-defaults.
>
> For a long time now, gccgo has been stuck at an implementation of Go
> 1.18, but even then, it's only a *partial* implementation of 1.18
> (notably missing generics).
>
> As noted and discussed in the CC'd https://bugs.debian.org/961916,
> bin:gccgo-go's version is misleading at best and actively harmful at
> worst, because it *looks* like it's 1.24, and this is where I think
> the overlap with the proposal to update to 1.26 appears - that number
> drifts even further from any truth.
>
> In ideating on solutions, I was thinking about doing something really
> goofy, like having bin:gccgo-go have a Version: that's 1.18 or
> something, but that ship has sailed (we can't downgrade in the
> archive), and it would be really poor behavior for one source package
> to do that anyhow.
>
> So concretely, what I'd propose for src:golang-defaults 1.26+ is that
> we remove all traces of gccgo entirely instead.  This is somewhat
> disruptive, but I don't think it's unreasonable.  Every interesting
> architecture is currently supported by upstream golang-go, gccgo
> hasn't been a suitable GOROOT_BOOTSTRAP for Go itself for several
> versions now, and gccgo is a very outdated implementation.  On top of
> all that, I strongly doubt there are many (if any) meaningful Go
> packages left in the archive that really successfully build with
> gccgo.
>
> I am going to work on an even more concrete MR for review after
> sending this email. 🙇

As promised: https://salsa.debian.org/go-team/compiler/golang-defaults/-/merge_requests/5

(and a tiny follow-up to remove the last bits of Perl code from the
package: https://salsa.debian.org/go-team/compiler/golang-defaults/-/merge_requests/6)

♥,
- Tianon

[toc] | [prev] | [next] | [standalone]

#1282727 — Bug#961916: Bug#1126733: Current status of golang-1.26

[Multipart message — attachments visible in raw view] — view raw

Am 19.02.26 um 07:10 schrieb Tianon Gravi:
> It's a tiny bit tangential, so apologies for that, but I think it
> would probably be prudent to finally do something about gccgo too,
> while we're opening the hood on src:golang-defaults.
> 
> For a long time now, gccgo has been stuck at an implementation of Go
> 1.18, but even then, it's only a *partial* implementation of 1.18
> (notably missing generics).
> 
> As noted and discussed in the CC'd https://bugs.debian.org/961916,
> bin:gccgo-go's version is misleading at best and actively harmful at
> worst, because it *looks* like it's 1.24, and this is where I think
> the overlap with the proposal to update to 1.26 appears - that number
> drifts even further from any truth.
> 
> In ideating on solutions, I was thinking about doing something really
> goofy, like having bin:gccgo-go have a Version: that's 1.18 or
> something, but that ship has sailed (we can't downgrade in the
> archive), and it would be really poor behavior for one source package
> to do that anyhow.
> 
> So concretely, what I'd propose for src:golang-defaults 1.26+ is that
> we remove all traces of gccgo entirely instead.  This is somewhat
> disruptive, but I don't think it's unreasonable.  Every interesting
> architecture is currently supported by upstream golang-go, gccgo
> hasn't been a suitable GOROOT_BOOTSTRAP for Go itself for several
> versions now, and gccgo is a very outdated implementation.  On top of
> all that, I strongly doubt there are many (if any) meaningful Go
> packages left in the archive that really successfully build with
> gccgo.

Hi Tianon,

thanks for raising this topic. I think it's a very sensible idea. I
wouldn't mind dropping gccgo from the golang-defaults package. I've
already looked at your MRs on salsa, and from a quick glance, both MRs
look good to me (but I haven't tested them yet).

However, I'd really like to move the default compiler to golang-1.26
rather sooner than later, because golang-1.24 is no longer supported by
upstream after the release of golang-1.26.
You know that, most probably. :-)

So I'm wondering if it might be better to upload an updated
golang-defaults package in the next few days (still *with* gccgo)? We'd
have more time to roll out your MRs in a later upload, then. This way,
we could wait for more opinions from other golang-compiler team members.

On the other hand, I don't know how many people are currently really
involved in this team. :-)

Regards,Tobias

[toc] | [prev] | [next] | [standalone]

#1284171 — Bug#1126733: Current status of golang-1.26

Control: tags -1 confirmed

On 2026-02-18 19:56:59 +0100, Dr. Tobias Quathamer wrote:
> Dear release team,
> 
> golang-1.26 has been released and is already available in unstable (and
> hopefully also in testing in a few hours).
> 
> About two weeks ago, I've written to you that there are 73 packages
> which FTBFS during a rebuild of 2772 golang packages.
> 
> Out of those 73 packages, 8 were already known to FTBFS with the current
> golang-1.24 compiler, leaving 65 new FTBFS bugs.
> 
> I've already fixed some issues in other packages, so this is the current
> status:
> 
> - 2772 packages tested
> - 21 new FTBFS bugs
> 
> I'm confident that we can handle those remaining build failures within
> the golang package team.
> 
> So, if you don't have any objections, I plan to switch the default
> golang compiler to 1.26 in the next few days.
> 
> Thoughts?

Go ahead.

Cheers
-- 
Sebastian Ramacher

[toc] | [prev] | [next] | [standalone]

#1286762 — Bug#1126733: Current status of golang-1.26

[Multipart message — attachments visible in raw view] — view raw

Am 01.03.26 um 19:48 schrieb Sebastian Ramacher:
>> So, if you don't have any objections, I plan to switch the default
>> golang compiler to 1.26 in the next few days.
>>
>> Thoughts?
> 
> Go ahead.
> 
> Cheers

Hi Sebastian,

almost all build failures have been resolved by now. There are two
packages left which show a regression in the autopkgtests.

- golang-gonum-v1-gonum/0.15.1-1

This one should be resolved tomorrow, when the new upload (0.15.1-3) has
migrated to testing.

- victoriametrics/1.112.0+ds1-4

That package is unfortunately not easy to solve. It builds fine with Go
1.24 (in testing), but FTBFS with Go 1.26. I'm not able to fix this
myself. The package will get removed from testing in a week (on 28 March
due to #1129170).

As I understand it, those two packages are the last ones holding off the
migration of golang-defaults to testing. So we could wait one week for
the automatic removal of victoriametrics from testing.

However, I was wondering if it would be a valid solution to finish the
Golang 1.26 migration to testing if the release team would add a hint
for golang-defaults to ignore the failing autopkgtest for
victoriametrics? Or maybe even remove the package from testing a bit
earlier?

Regards,
Tobias

[toc] | [prev] | [next] | [standalone]

#1287124 — Bug#1126733: Current status of golang-1.26

On 2026-03-21 15:10:50 +0100, Dr. Tobias Quathamer wrote:
> Am 01.03.26 um 19:48 schrieb Sebastian Ramacher:
> >> So, if you don't have any objections, I plan to switch the default
> >> golang compiler to 1.26 in the next few days.
> >>
> >> Thoughts?
> > 
> > Go ahead.
> > 
> > Cheers
> 
> Hi Sebastian,
> 
> almost all build failures have been resolved by now. There are two
> packages left which show a regression in the autopkgtests.
> 
> - golang-gonum-v1-gonum/0.15.1-1
> 
> This one should be resolved tomorrow, when the new upload (0.15.1-3) has
> migrated to testing.
> 
> - victoriametrics/1.112.0+ds1-4
> 
> That package is unfortunately not easy to solve. It builds fine with Go
> 1.24 (in testing), but FTBFS with Go 1.26. I'm not able to fix this
> myself. The package will get removed from testing in a week (on 28 March
> due to #1129170).
> 
> As I understand it, those two packages are the last ones holding off the
> migration of golang-defaults to testing. So we could wait one week for
> the automatic removal of victoriametrics from testing.
> 
> However, I was wondering if it would be a valid solution to finish the
> Golang 1.26 migration to testing if the release team would add a hint
> for golang-defaults to ignore the failing autopkgtest for
> victoriametrics? Or maybe even remove the package from testing a bit
> earlier?

Thanks for the update. I have added a hint to ignore these two
autopkgtest regressions.

Cheers
-- 
Sebastian Ramacher

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web