Changing build dependency to golang-go (>= 2:1.14~) from golang-any (>=
2:1.14~) works. I wonder why gccgo-go is selected over golang-go in
buster-backports though. It builds fine in sid when gccgo-go (>=
2:1.14~) is used as build dependency.

Command used to build the backport is,

sbuild -A -s --force-orig-source -c buster-amd64-sbuild
--extra-repository='deb http://deb.debian.org/debian buster-backports 
main' --extra-repository='deb http://incoming.debian.org/debian-buildd
buildd-buster-backports main' --build-dep-resolver=aptitude
--no-run-lintian

github.com/cloudflare/tableflip
# github.com/cloudflare/tableflip
src/github.com/cloudflare/tableflip/fds.go:82:13: error: reference to
undefined identifier ‘net.ListenConfig’
  lc *net.ListenConfig
             ^
src/github.com/cloudflare/tableflip/fds.go:85:47: error: reference to
undefined identifier ‘net.ListenConfig’
 func newFds(inherited map[fileName]*file, lc *net.ListenConfig) *Fds {
                                               ^
src/github.com/cloudflare/tableflip/fds.go:91:13: error: reference to
undefined identifier ‘net.ListenConfig’
   lc = &net.ListenConfig{}
             ^
src/github.com/cloudflare/tableflip/fds.go:91:25: error: expected
‘;’ or ‘}’ or newline
   lc = &net.ListenConfig{}
                         ^
src/github.com/cloudflare/tableflip/fds.go:94:2: error: expected
declaration
  return &Fds{
  ^
src/github.com/cloudflare/tableflip/fds.go:99:1: error: expected
declaration
 }
 ^
src/github.com/cloudflare/tableflip/upgrader.go:29:16: error: reference
to undefined identifier ‘net.ListenConfig’
  ListenConfig *net.ListenConfig
                ^
src/github.com/cloudflare/tableflip/fds.go:141:2: error: not enough
arguments to return
  return f.listenerLocked(network, addr)
  ^
src/github.com/cloudflare/tableflip/fds.go:156:2: error: argument 1
must be a map
  delete(f.inherited, key)
  ^
src/github.com/cloudflare/tableflip/fds.go:223:2: error: not enough
arguments to return
  return f.packetConnLocked(network, addr)
  ^
src/github.com/cloudflare/tableflip/fds.go:249:2: error: argument 1
must be a map
  delete(f.inherited, key)
  ^
src/github.com/cloudflare/tableflip/fds.go:272:2: error: argument 1
must be a map
  delete(f.inherited, key)
  ^
src/github.com/cloudflare/tableflip/fds.go:294:2: error: argument 1
must be a map
  delete(f.inherited, key)
  ^
src/github.com/cloudflare/tableflip/fds.go:319:2: error: argument 1
must be a map
  delete(f.inherited, key)
  ^
src/github.com/cloudflare/tableflip/fds.go:339:2: error: argument 1
must be a map
  delete(f.inherited, key)
  ^
src/github.com/cloudflare/tableflip/fds.go:349:2: error: range clause
must have array, slice, string, map, or channel type
  for key, file := range f.used {
  ^
src/github.com/cloudflare/tableflip/fds.go:360:2: error: range clause
must have array, slice, string, map, or channel type
  for key, file := range f.inherited {
  ^
src/github.com/cloudflare/tableflip/fds.go:393:2: error: range clause
must have array, slice, string, map, or channel type
  for _, file := range f.used {
  ^
src/github.com/cloudflare/tableflip/fds.go:403:2: error: range clause
must have array, slice, string, map, or channel type
  for key, file := range f.used {
  ^
src/github.com/cloudflare/tableflip/upgrader.go:71:13: error: reference
to undefined name ‘newUpgrader’
  upg, err = newUpgrader(stdEnv, opts)
             ^
src/github.com/cloudflare/tableflip/upgrader.go:80:3: error: return
with value in function with no return type
   return nil, errors.New("couldn't determine initial working
directory")
   ^
src/github.com/cloudflare/tableflip/upgrader.go:85:3: error: return
with value in function with no return type
   return nil, err
   ^
src/github.com/cloudflare/tableflip/upgrader.go:107:2: error: return
with value in function with no return type
  return u, nil
  ^
src/github.com/cloudflare/tableflip/fds.go:349:6: error: invalid type
for range clause
  for key, file := range f.used {
      ^
src/github.com/cloudflare/tableflip/fds.go:349:6: error: invalid type
for range clause
src/github.com/cloudflare/tableflip/fds.go:360:6: error: invalid type
for range clause
  for key, file := range f.inherited {
      ^
src/github.com/cloudflare/tableflip/fds.go:360:6: error: invalid type
for range clause
src/github.com/cloudflare/tableflip/fds.go:393:6: error: invalid type
for range clause
  for _, file := range f.used {
      ^
src/github.com/cloudflare/tableflip/fds.go:403:6: error: invalid type
for range clause
  for key, file := range f.used {
      ^
src/github.com/cloudflare/tableflip/fds.go:403:6: error: invalid type
for range clause
src/github.com/cloudflare/tableflip/upgrader.go:221:3: error: expected
channel
   case request := <-u.upgradeC:
   ^
src/github.com/cloudflare/tableflip/upgrader.go:256:3: error: expected
channel
   case request := <-u.upgradeC:
   ^
src/github.com/cloudflare/tableflip/upgrader.go:83:34: error: argument
1 has incompatible type
  parent, files, err := newParent(env)
                                  ^
src/github.com/cloudflare/tableflip/upgrader.go:83:34: error: invalid
use of type
src/github.com/cloudflare/tableflip/upgrader.go:163:23: error: expected
channel
  case err = <-u.parent.result:
                       ^
src/github.com/cloudflare/tableflip/upgrader.go:164:16: error: expected
channel
  case err = <-u.parentErr:
                ^
src/github.com/cloudflare/tableflip/upgrader.go:185:10: error: expected
channel
  case <-u.stopC:
          ^
src/github.com/cloudflare/tableflip/upgrader.go:187:10: error: expected
channel
  case <-u.exitC:
          ^
src/github.com/cloudflare/tableflip/upgrader.go:189:8: error: expected
channel
  case u.upgradeC <- response:
        ^
src/github.com/cloudflare/tableflip/upgrader.go:214:10: error: expected
channel
   case <-processReady:
          ^
src/github.com/cloudflare/tableflip/upgrader.go:217:11: error: expected
channel
   case <-u.stopC:
           ^
src/github.com/cloudflare/tableflip/upgrader.go:221:22: error: expected
channel
   case request := <-u.upgradeC:
                      ^
src/github.com/cloudflare/tableflip/upgrader.go:256:22: error: expected
channel
   case request := <-u.upgradeC:
                      ^
src/github.com/cloudflare/tableflip/upgrader.go:265:11: error: expected
channel
   case <-u.stopC:
           ^

gccgo-go (>= 2:1.14)  doesn't mean this version implements go1.14 features.
As in buster-backports, the gccgo-go points to gccgo-8, which
implements go1.10 features.
You can always check what version of go spec is implemented, by
running `go version`.

This is the go1.11 feature. See https://github.com/golang/go/issues/9661

As gcc maintainers are unlikely to backport gcc, so there's nothing we
can do to make gccgo build this.

What can be fixed is why your build env picks up gccgo instead of golang-go.

Its a bit misleading, but thanks for explaining. I thought it could be
the older gcc version, hence confirmed on sid with newer gcc version.

Can't gccgo-8 then provide gloang-any (=2:1.10)?

That will also work. I think if gccgo-8 did not Provide golang-any
2:1.14 (and instead provided only golang-any 2:1.10), aptitude
(build-dep resolver) would have picked golang-go correctly.

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

(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

Am 19.02.26 um 07:10 schrieb Tianon Gravi:

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

Yeah, that's sane -- this will create some cruft/churn that could
potentially delay migration, so I agree, let's get 1.26 in first, then
do this removal (I was hoping we could squeeze it in, but the
possibility of delaying 1.26 over this isn't worth it).  I'll note the
same on the MRs.

I really appreciate all the work you've done here, fwiw - coordinating
with the release team, coordinating test builds, etc.  I'm happy to
help shoulder some of the package update work if you'd like (once/if
we get the RT green-light), but happy to let you do it if you'd prefer
/ are already geared up. 👍

♥,
- Tianon

Am 20.02.26 um 04:27 schrieb Tianon Gravi:

Hi Tianon,

thanks for those nice words, much appreciated. :-)

Regarding your offer to help with package updates, that would be very
welcome. I've not prepared anything yet, so your help would be great.

As I've written to the release team, I expect around 21 *new* FTBFS
bugs. However, I think most (if not all) of them are due to outdated
golang packages, not really due to golang-1.26. Therefore, I hope that
uploading new releases of those failing packages will resolve the build
failures. We'll see.

Regards,
Tobias