packer 1.9.4

[edigaryev]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 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 HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

Sets the linker flag -B gobuildid so Go < 1.24 builds with a UUID required for macOS Sequoia's firewall to grant access to local network resources.

Similarly to #198462.

Fixes:

• Occasional Timeout waiting for SSH cirruslabs/packer-plugin-tart#79

[iMichka]

Thanks. The formula is disabled though and will be dropped on 2025-09-27

[github-actions]

🤖 An automated task has requested bottles to be published to this PR.

[github-actions]

⚠️ Bottle publish failed.

[edigaryev]

@iMichka any idea if the bottle push failure is transient, or there's could be something wrong with my changes? 🤔

[ZhongRuoyu]

The fact that this formula is disabled means that we don't build it anymore, so we have nothing to publish. It also means that this formula is no longer installable so I'm afraid this change will not affect any end user.

[edigaryev]

The fact that this formula is disabled means that we don't build it anymore, so we have nothing to publish. It also means that this formula is no longer installable so I'm afraid this change will not affect any end user.

I don't understand why it needs to be disabled, though. Should we deprecate it instead?

1.9.4 is not affected by the BUSL-1.1 change and is still usable.

/cc @iMichka

[edigaryev]

Should we deprecate it instead?

Implemented in 8a58e85 (had to rebase into 354d172, though, to pass the commit style test).

Here's one more example of a license change that uses deprecate! instead of disable!:

homebrew-core/Formula/t/tart.rb

Lines 16 to 17 in cb88b10

	# https://tart.run/blog/2023/02/11/changing-tart-license/
	deprecate! date: "2024-09-16", because: "switched to a DFSG-incompatible license"

Looks like a better way to do it.

[ZhongRuoyu]

I don't understand why it needs to be disabled, though.

Because it had been deprecated for a year. This follows the standard formula deprecation cycle. And it was deprecated because it was relicensed to a non-free license, as documented in the formula.

Should we deprecate it instead?

I see that your change to this formula is simple enough and only affects the version before the re-licensing happened. However, I don't think this is a strong enough reason to re-enable the formula. I'm asking @Homebrew/core for opinions.

[edigaryev]

Because it had been deprecated for a year. This follows the standard formula deprecation cycle.

Can you please quote the relevant paragraph from that document?

Because I only see a rule about removing the formulas that have been disabled for over a year, and nothing about disabling a deprecated formula after a year.

[ZhongRuoyu]

https://docs.brew.sh/Deprecating-Disabling-and-Removing-Formulae#disabling:

The most common reasons for disabling a formula are:

• it has been deprecated for a long time

[edigaryev]

it has been deprecated for a long time

I see, thanks! I'm going to close this PR then, sorry for the noise.

Also just realized that HashiCorp now has their own tap where this change can be introduced instead.

[ZhongRuoyu]

Yes, you're better off using a third-party tap since we don't accept such a non-free formula here in the official tap. Thanks for being understanding, @edigaryev!