bump(main/golang): 1.26.0

[luisdavim]

Bump golang to 1.26

[TomJo2000]

You'll also need to update the version and SHA256 sum in the termux_setup_golang function.

termux-packages/scripts/build/setup/termux_setup_golang.sh

Lines 6 to 7 in f08abf4

	local TERMUX_GO_VERSION=go1.25.6
	local TERMUX_GO_SHA256=f022b6aad78e362bcba9b0b94d09ad58c5a70c6ba3b7582905fababf5fe0181a

[luisdavim]

You'll also need to update the version and SHA256 sum in the termux_setup_golang function.

termux-packages/scripts/build/setup/termux_setup_golang.sh

Lines 6 to 7 in f08abf4

	local TERMUX_GO_VERSION=go1.25.6
	local TERMUX_GO_SHA256=f022b6aad78e362bcba9b0b94d09ad58c5a70c6ba3b7582905fababf5fe0181a

Done, thanks

[luisdavim]

Humm, the shas on those 2 files were different, is there some other process to get the sha for the second file? I just used the same one on both...

I followed the instructions from the CONTRIBUTING.md...

[TomJo2000]

Yes they are different.
The one in the build.sh is the source tarball, the one in the setup function is a precompiled binary for the build host.

You should be able to get the checksum for the second one from the error message it throws for an incorrect checksum.

[luisdavim]

in the failed tests I see, for example that the sha for nexttrace changed, should I go and update it in this PR?

[TomJo2000]

Alright looks like usql, nextrace and kubo are failing to rebuild.
On a semi-related note I'd like to take a look at improving the CI summary for the package validation workflows, it's a bit hard to read currently.

[TomJo2000]

in the failed tests I see, for example that the sha for nexttrace changed, should I go and update it in this PR?

Yes that should be done in this PR and can be a separate commit for each package that needs a build fix.
We've had situations before where e.g. zrok has "retagged" a release causing the checksum to change, the same might be the case with nexttrace here.

[luisdavim]

I've updated the checksum for nexttrace but I'm not quite sure what's failing on the other packages, I'll try to build them locally and see if I can get some more details that way.

[luisdavim]

ok, so, the issue with usql is that it indirectly depends on github.com/cockroachdb/swiss and it's using a version that is prior to cockroachdb/swiss#50 it's a bit odd how that package works, no real changes are required to get it to work with 1.26 but it needs to be explicitly enabled....

[luisdavim]

@TomJo2000 I got the package to build on my local and pushed the solution for each on a separate commit, I'm not sure if the approach I took is to hacky but it seems to work, at least I was able to reproduce the failures before and not anymore after...

Please have a look when you have some time, and let me know what you think.

[TomJo2000]

Those packages that are getting rebuilt are gonna need revision bumps.
You can use our semi-automated revbump utility for that.
./scripts/bin/revbump usql nexttrace kubo

You can also automatically mark those changes for squashing using;
git commit --squash=<commitish>, your tab completion should be able to help you out with the hashes.
Those will then get moved into position automatically the next time you do a git rebase -i, given that the --autosquash flag is also passed, or you have set;

[rebase]
	autosquash = true

in your ~/.config/git/config (or ~/.gitconfig).

[luisdavim]

I've fixed the typo, and bumped the versions and kept a commit per change, is that what you were requesting?

[TomJo2000]

Yep looks good to me.
Thank your for your contribution, I'm just gonna wait for the validation CI to finish before merge.