Build issues with go-1.24 on Fedora

[ganto]

Is there an existing issue for this?

• There is no existing issue for this bug

Is this happening on an up to date version of Incus?

• This is happening on a supported version of Incus

Incus system details

Issue happens when building Incus for Fedora 42/Rawhide from https://github.com/ganto/copr-lxc4/blob/master/incus/incus.spec via Fedora COPR build service.

Build environment

$ go version
go version go1.24.1 linux/amd64
$ rpm -q go-srpm-macros go-rpm-macros
go-srpm-macros-3.6.0-6.fc42.noarch
go-rpm-macros-3.6.0-6.fc42.x86_64

Also see: https://lists.fedorahosted.org/archives/list/golang@lists.fedoraproject.org/thread/AQRBENDKBYJLGX5DKQTSLNOI6W4HIHT3/

Build log

Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.mXR0yd
+ umask 022
+ cd /builddir/build/BUILD/incus-6.11-build
+ cd incus-6.11
+ export GOPATH=/builddir/build/BUILD/incus-6.11-build/BUILDROOT//usr/share/gocode:/usr/share/gocode
+ GOPATH=/builddir/build/BUILD/incus-6.11-build/BUILDROOT//usr/share/gocode:/usr/share/gocode
+ export 'CGO_LDFLAGS_ALLOW=(-Wl,-wrap,pthread_create)|(-Wl,-z,now)'
+ CGO_LDFLAGS_ALLOW='(-Wl,-wrap,pthread_create)|(-Wl,-z,now)'
+ GO_LDFLAGS=' -X github.com/lxc/incus/version=6.11'
+ GO_TEST_FLAGS='-buildmode pie -compiler gc -v -tags libsqlite3'
+ GO_TEST_EXT_LD_FLAGS='-Wl,-z,relro -Wl,--as-needed  -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes  '
+ go-rpm-integration check -i github.com/lxc/incus -b /builddir/build/BUILD/incus-6.11-build/incus-6.11/_build/bin -s /builddir/build/BUILD/incus-6.11-build/incus-6.11/_build -V 6.11-0.1.fc43 -p /builddir/build/BUILD/incus-6.11-build/BUILDROOT -g /usr/share/gocode -r '.*example.*' -v -t github.com/lxc/incus/test -d github.com/lxc/incus/cmd/lxc-to-incus
Testing    in: /builddir/build/BUILD/incus-6.11-build/incus-6.11/_build/src
         PATH: /builddir/build/BUILD/incus-6.11-build/incus-6.11/_build/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin
       GOPATH: /builddir/build/BUILD/incus-6.11-build/incus-6.11/_build:/builddir/build/BUILD/incus-6.11-build/BUILDROOT//usr/share/gocode:/usr/share/gocode:/usr/share/gocode
  GO111MODULE: off
      command: go test -buildmode pie -compiler gc -v -tags libsqlite3 -ldflags " -X github.com/lxc/incus/version=6.11 -extldflags '-Wl,-z,relro -Wl,--as-needed  -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes  '"
      testing: github.com/lxc/incus
github.com/lxc/incus/client
# github.com/lxc/incus/client
./incus.go:249:59: non-constant format string in call to github.com/lxc/incus/shared/api.StatusErrorf
./incus.go:303:18: non-constant format string in call to github.com/lxc/incus/shared/logger.Debugf
./incus.go:389:16: non-constant format string in call to github.com/lxc/incus/shared/logger.Debugf
./incus.go:439:16: non-constant format string in call to github.com/lxc/incus/shared/logger.Debugf
FAIL	github.com/lxc/incus/client [build failed]

Current behavior

Incus cannot successfully be built as RPM via Fedora >=42 build system.

Expected behavior

Successful build and test completion on Fedora >=42.

Steps to reproduce

I tried for about one hour to reproduce the bug without the RPM machinery but unfortunately I failed to do so. I'm not exactly sure what in the new Go version is triggering the error (according to the linked Fedora thread it's supposed to be some changes in go vet). If it's required I can dig deeper into it.

[stgraber]

We've seen one other report of this before but it's indeed because of odd distro tooling.

Our build process doesn't require the codebase to be go vet clean. A normal version of the Go compiler has no issue building our code.

I have a background project of slowly making the codebase pass the usual set of static analysis tools, but last I checked, we had several thousands different warnings to investigate and either correct or override.

So we're looking at a multi month of not multi year effort to slowly clear all that. Our normal static analysis setup requires all new and all modified code to comply while allowing pre-existing code to remain the way it is.

So long story short, those warnings are an issue with your distribution, the upstream compiler does not issue them. The few ones you showed are also only the tip of the iceberg as vet fails on the first non-compliant package.
Fixing just those would just get you another list of others to fix.

[ganto]

Ok, sorry for the duplicate I missed that. Linking it here for completeness sake: #1779