Go 1.14.1

[leonklingele]

• Have you followed the guidelines for contributing?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

---

previous upgrade, #50687

[EricFromCanada]

Build was stuck for hours on brew test --verbose armor.

[chenrui333]

@BrewTestBot test this please

[uudashr]

I think we need to re-run the CI pipeline

[SMillerDev]

We don't, the issues need to be resolved.

[pete-woods]

For those following along at home, the issues are with downstream packages.

Though it does look like several of them are transient (various git cloning / ref errors).

[bmhatfield]

Go 1.13.5 got stuck in a similar fashion for weeks here.

I'm just a bystander, but I really like getting Go releases from Homebrew. I'm nervous folks will stop trying to maintain the Homebrew Go releases if every one of them gets held up due to issues totally unrelated to Go.

In the case of 1.13.5, the problems were unresolvable - @fxcoudert ended up just forcing the merge.

[SMillerDev]

Everyone is able to post updates to homebrew formulae. If nobody else makes a PR you can make one @bmhatfield.

[uudashr]

Not sure this is the cause or not, previously for go 1.4 the build bottles exec brew test-bot --ci-pr, but here for go.1.4.1 the build bottles exec brew test-bot with no additional flags.

[jonchang]

We may have to start doing versioned migrations like with python@3.8 if go version bumps break a ton of stuff.

[bayandin]

• etcd fixed in etcd 3.4.5 #51930
• apache-brooklyn-cli fixed in apache-brooklyn-cli 1.0.0 #52121

[Bo98]

I don't think anything has ever been wrong with a Go release

What we found is that there has been but the previous testing system was insufficient at catching broken formulae. After Go 1.14.0, there were a few formulae which did not properly build from source anymore.

This is the first version to have properly fully tested building dependents from source, so some of the failures are formulae which have been broken for a while but were not caught. In the future, it should only fail when Go breaks things, and probably in fewer numbers.

[roopakv]

@Bo98 are there fixes that I could help with to get this moving along? happy to upgrade / fix other formulae that depend on this.

[jonchang]

are there fixes that I could help with to get this moving along? happy to upgrade / fix other formulae that depend on this.

Please open pull requests (like in #51930) that fix one of these formulae using the listed brew command:

brew install -s <formula>

• anycable-go anycable-go: fix build for go 1.14 #52154
• apache-brooklyn-cli apache-brooklyn-cli 1.0.0 #52121
• assh assh: update sha and test block #52043
• charm
• dvm
• etcd etcd 3.4.5 #51930
• gor
• oauth2_proxy oauth2_proxy 5.0.0 #52156
• packer packer 1.5.5 #52158
• perkeep perkeep: depend on go@1.10 #52131
• reposurgeon docbook-xsl: introduce stack usage patch and URL rewrites #52041
• stout stout: fix build #52135
• syncthing-inotify syncthing-inotify: delete #52139
• terraform@0.11 terraform@0.11: fix build with Go 1.14 #52140
• tunnel tunnel: depend on go@1.13 #52189
• volt volt: remove GOPATH, add patch for Go 1.14 #52157
• wellington

brew test <formula>

• dashing dashing: fix ruby-doc sha mismatch and simplify build steps #52042
• prest prest: remove GOPATH, fix version under newer Go #52133

[ydnar]

wellington needs a pull request in its upstream repo to work with Go modules. It’s unlikely to build without significant patches in the Homebrew formula.

[roopakv]

same for tunnel and I have sent them a patch.

at a higher level, If these are already broken, why block go 1.14.1 behind these. I think there should be fixes for them, but blocking behind 1.14.1 is not necessary?

I specifically care because 1.14 broke testing with the -json flag and I cant move to 1.14.1 till i can make sure i dont break my developers.

[Bo98]

Yes, I can see this pull request being merged without the likes of wellington being fixed. It's just good to get the majority fixed rather than just kicking the problem down the road for 1.14.2 or 1.15.0.

[roopakv]

@Bo98

The following need updates from the packages. I have reached out to gor and made a PR for tunnel

gor 
tunnel
wellington
dvm

Would you be ok moving the list an issue and unblocking this PR by force merging?

[Bo98]

Yes, I'm fine with that.

[bayandin]

Can we switch these formulae to go@1.13 maybe?
Don't really like an idea of having formulae that can't be built

[Bo98]

I agree. Though, similarly to some Rust dependents, some have been broken for some time (and therefor not caused by Go 1.14.1):

• wellington hasn't been buildable for well over a year. I don't know if any Go we ship will work with it. A release was requested in 2018.
• dvm has also been broken for at least a few months. go@1.13 will not fix it, but maybe something prehistoric will.
• perkeep only works with go@1.10. This isn't really acceptable (see linked PR for discussion), but the next release will support newer Go. ETA: who knows?
• tunnel could probably use go@1.13. Fixed in tunnel: depend on go@1.13 #52189
• gor too. also fails on go@1.13. It has been broken for several months.
• charm simply doesn't build from source anywhere anymore. It pulls in a dependency which no longer exists. Only the current HEAD build works.

[roopakv]

@Bo98 I have made #52184 to move this to a global issue and unblock 1.14.1. Lets take the discussion there and push this PR through?

[chrispassas]

@chenrui333 thank you for helping move this forward. For what its worth I've observed these types of issues on the Golang version updates in the past. I don't know if its something specific to this formula but it's not uncommon for these to get stuck for several days or longer.

It always seems something unrelated to the actual Go update is the blocker.

[chenrui333]

@chrispassas, moving forward is always our goal, and as maintainer, we also want to make our ecosystem safe for everyone (the process is being improved as we speak, and does need everyone's involvement to keep this community project healthy! 😄 )

[chenrui333]

Running the final Jenkins build before shipping this out (I will see this through today)

[Bo98]

I've observed these types of issues on the Golang version updates in the past

Considering this is the first Go pull request to have tested dependents from source, it's actually a little different.

Previous Go pull requests tested runtime linkage. In the Go world, this is a pretty useless test besides for godep. Now it actually tests building from source, so in cases where Go does break something - and it has on several occasions before - then it's now picked up properly from now on. Because this is the first time we've managed to try this workflow on Go, this pull request alerted some formulae which should have been fixed with Go 1.14.0 - a release which broke a significant number of old software.

I merged the last of those today, moving tunnel to use go@1.13. The rest have been broken for longer - we'll need to decide at some point before the next Go release what to do with them.

[chrispassas]

@Bo98 I only mean that I've seen brew upgrade go delayed for past releases. I don't know exactly what caused the delay accepting the pull request in those past cases.

If you are just pulling the exact source from the Go Project that is already compiled for Mac OS what type of problems are you testing for?

I assume if there is an issue with the Go release on Mac OS x.x.x it would affect all users even if they didn't use brew to install.

Is brew taking on the responsibility of testing Go releases? It seems like at least in this case the Go team should own that and brew should not be concerned with it.

I'm not saying that should be the case for all brew updates but specifically Go releases I would argue that makes sense.

[Bo98]

If you are just pulling the exact source from the Go Project that is already compiled for Mac OS what type of problems are you testing for?

We do not, and never will, use pre-built binaries. We compile Go from source.

Is brew taking on the responsibility of testing Go releases? It seems like at least in this case the Go team should own that and brew should not be concerned with it.

It isn't necessarily about whether Go works, but whether everything in homebrew-core that depends on Go works properly.

Go 1.14.0 proved the need to test that. A significant number of formulae no longer built from source after we merged Go 1.14.0, which left some users unable to install those formulae.

[chrispassas]

@Bo98 sorry I just looked and I see you are pulling the source files to compile and not the prebuilt files from the Go Team. If your are compiling your self its understandable to have your own testing.

It sounds like your saying some of the brew service is using Go and updating this package could cause other brew services to break?

Does that mean any projects that brew uses are more likely to encounter delayed releases because they're dependencies might fail with new updates?

Sorry, I'll stop asking questions, its just interesting to learn more about how brew works.

[SMillerDev]

It sounds like your saying some of the brew service is using Go and updating this package could cause other brew services to break?

https://formulae.brew.sh/formula/go#default shows that go got installed 22577 times in the last 30 days to build something else in homebrew. And most users don't build anything in homebrew from source. That should indicate that a lot of things are dependent on homebrew's Go.

[Bo98]

Does that mean any projects that brew uses are more likely to encounter delayed releases because they're dependencies might fail with new updates?

The delay this time was particularly affected because this is the first time Go's gone through improved testing of dependents - so the number of detected "breakages" were higher since there will have been some that went unnoticed in past Go pull requests.

However, not all Go versions will break things. If all these problems were fixed when 1.14.0 were merged, Go 1.14.1 would have likely been merged fairly quickly. If Go 1.14.2 was released tomorrow, it would likely be merged within a day.

[mgaffney]

@chenrui333 can you add a comment on why this was closed and not merged?

[mrz1836]

@chenrui333 can you add a comment on why this was closed and not merged?

@mgaffney Not sure - but Go 1.14.1 is now available in homebrew ;-)

[chenrui333]

The process of merging the PRs for homebrew-core formulae is thru brew pull process (which is involved with merge the PRs through merge commits as well as merge the published bottle hashes).

Published bottles are artifacts published into Bintray which would allows users to quickly install the formulae, and they dont have to rebuild the software from source.

However, when I tried to merge this PR, I only got one version of bottle published, and now@Bo98 and I are fixing the bottle issues.

[chenrui333]

Not sure - but Go 1.14.1 is now available in homebrew ;-)

Yes, Go 1.14.1 is in here, I will announce in here once we fixed the issue for Mojave and HighSierra.

[tupos]

I wanted to ask, why there is no more prebuilt bottles for mojave and high sierra? Are you planing to provide them?

[chenrui333]

I wanted to ask, why there is no more prebuilt bottles for mojave and high sierra?

~Simple answer is the PR was created 8 days ago, somehow the mojave and highsierra bottles are gone when I tried to merge the PR. ~

Bintray permanently deletes unpublished bottles after a week.

That is just unfortunate bad timing.

Now we were trying to build all bottles.

[tupos]

Now we were trying to build all bottles.

Ok, Thanks for the info.

[Bo98]

Yes, our merge process doesn't show as "merged" in GitHub. It's normal for it to appear as "closed".

[Bo98]

Mojave and High Sierra bottles are now available.

[chenrui333]

Thanks @Bo98!!

[tmm1]

golang 1.14.2 has been released

[Bo98]

Thanks for the heads up. I've opened #52774.