- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Tue, Oct 14
Thu, Oct 9
Wed, Oct 8
Tue, Oct 7
Wed, Oct 1
Tue, Sep 23
Sep 18 2025
Sep 17 2025
Sep 11 2025
Sep 9 2025
Sep 7 2025
Sep 4 2025
Sep 1 2025
Aug 23 2025
Aug 22 2025
Aug 19 2025
Aug 15 2025
Aug 14 2025
Aug 12 2025
Aug 7 2025
Sorry about the really long silence there. I rolled this into today's updates to go124 and go123. I opted not to change anything lower than that because those ports are EOL upstream and shouldn't exist (it's my fault that they still do). Thank you for submitting this!
Aug 6 2025
Aug 1 2025
Jul 29 2025
Jul 18 2025
Jul 14 2025
Jul 13 2025
Jul 12 2025
Jul 10 2025
Jul 9 2025
Jul 7 2025
Jul 4 2025
Jun 20 2025
Jun 13 2025
Jun 6 2025
Jun 4 2025
Jun 2 2025
May 30 2025
In D50595#1155305, @mengzhuo1203_gmail.com wrote:Thanks for review,
This change only affect download source code and binary for go itself.
The https://golang.org/dl/*.src.tar.gz redirect (HTTP 301) to go.dev/dl then Google blob file server.Other golang.org namespace library (golang.org/x) won't change AFAIK.
Good catch! I'm definitely in favor of switching, but:
May 28 2025
May 25 2025
In D49906#1153054, @kbowling wrote:Is there a way to vendor the alt toolchains? It is imperative this doesn't start downloading from the internet outside of the fetch step, the same standards things like Cargo, Maven, etc have in ports. As long as that is addressed I think the overall concept is fine now -- it will be awkward if we have to patch Go but hopefully that is not common.
May 23 2025
In D49906#1152227, @fuz wrote:The best way would be to set GOTOOLCHAIN=local when building Go ports, which disables the “fetch the appropriate toolchain” mechanism. This makes it impossible to build Go ports requiring too new toolchains, but then perhaps there's more of an incentive to have them packaged quickly.
May 22 2025
In D49906#1151683, @fuz wrote:If the test build shows that none of the ports fail with a more recent toolchain, I'm okay with only providing it. But what we must disable in the ports tree is the mechanism where Go tries to download a newer toolchain if it considers itself outdated. Downloading random toolchains at fetch time is not what we should be doing.
May 21 2025
So, I should have tagged this review in the commit, but I set go124 as the default as portmgr/pkgmgr seems to be swamped at the moment. Once we see how things build, we'll have a better picture of whether this will be a viable thing.
In D49906#1138522, @fuz wrote:I disagree with this step.
We should instead disable the feature where Go tried to download a toolchain and have Go err out instead. This can be achieved by setting GOTOOLCHAIN=local in the environment. Packages should always be built with our own toolchain, not the one provided by Google. The downloaded toolchain has none of our site patches, is outside of our control and we don't do this sort of thing anywhere else.
May 17 2025
May 13 2025
May 12 2025
May 11 2025
May 10 2025
May 7 2025
May 3 2025
May 2 2025
Apr 27 2025
Apr 25 2025
Apr 24 2025
Apr 23 2025
Apr 19 2025
In D49906#1138150, @kbowling wrote:In D49906#1137930, @adamw wrote:There's literally no difference between Go versions anymore, so we gain nothing by having multiple in the tree.
Ok, I'm tracking on the backward compat. Although I am skeptical about the last sentence, i.e. we will need an equal or newer compiler to handle all go.mod versions.
In D49906#1137925, @kbowling wrote:Is this really feasible? At first contact I would think this will create a lot of different problems than whatever supporting multiple versions currently does. Some projects have elaborate dependencies (i.e. multimedia/navidrome which I maintain) and we could get into common situations where it is either difficult to update go with a clean exp-run or we have to make a choice to regularly lose ports because tracking a modern version is more important.
@danilo are you able to please test build all the go ports?