homebrew-core

I'm in the camp of "if I can't build it, then it's not open source" so https://github.com/Homebrew/homebrew-core/blob/d314f3ebba9e7... is a good start, but there is no .../f/flutter.rb although there is https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=flutt... but I haven't been soaking in the AUR ecosystem long enough to be able to port it to Homebrew All those words to say that if there was a .github/workflow/release.yml showing the steps required to cook a release artifact that would be the best(?) documentation since it is kind of like a Dockerfile in that it's computer executable but mostly human readable I don't mean to poo-poo all the "supply chain security" effort, but you have to recognize that right now it's "trust me, bro" since https://github.com/Homebrew/homebrew-cask/blob/27c351ccb59fb... does check the sha256, and goo

Does `brew install mit-scheme` work? The homebrew formula says : https://github.com/Homebrew/homebrew-core/blob/8c0bb91eea9c8... : # Does not build: https://savannah.gnu.org/bugs/?64611 deprecate! date: "2023-11-20", because: :does_not_build Podman runs Linux containers in a VM in QEMU on MacOS. https://podman.io/docs/installation

Quoting[1] from Homebrew on Github: >> Looks like that Homebrew users (both macOS and Linux, both Intel and ARM) are unlikely affected? > Correct. Though we do not appear to be affected, this revert was done out of an abundance of caution. [1] https://github.com/Homebrew/homebrew-core/pull/167512

Is disabling the compromised repo the typical GitHub policy? My concern is there are monorepos used by package managers, like brew, that are a collection of thousands of projects [1]. These monorepos seem like a prime target for attack and if GitHub disables one because a malicious commit was merged then you've taken down an entire ecosystem. [1] https://github.com/Homebrew/homebrew-core

It's been reverted now: https://github.com/Homebrew/homebrew-core/blob/9a0603b474804...

Homebrew reverted to 5.4.6 once the maintainers became aware. The current understanding is that macOS is not affected, but that's not certain. [1]: https://github.com/Homebrew/homebrew-core/pull/167512

> right, but now you know even less about your setup when you some roadblock This is the same with a binary though. And with homebrew, you can't follow patches or flags used or if they change. - https://github.com/Homebrew/homebrew-core/blob/c964ad7fa53ad... - https://github.com/Homebrew/homebrew-core/blob/c964ad7fa53ad... - https://github.com/Homebrew/homebrew-core/blob/c964ad7fa53ad... Not arguing for good or bad, just saying that the problem isn't limited to this.

Thanks for taking the time. Can you help me understand? Because I didn't get this from the devs. Just looking at a random formula, am I correct to understand that this will use python 3.10 and NOT 3.12?[0] I understand ones like this[1] where there's a note about the issue with newer versions. What I'm trying to understand is if the python version is specified by the formula or it will default to the newest version. If it requires it to be specified in the formula then doesn't this make it contingent on the maintainer upgrading it every python version? I didn't verify [0], but it looks like it should work with later versions of python, and it it is still using 3.10 then isn't that essentially the maintainers "fault?" Because that's my concern. I can't see how something like this stays updated when it requires a maintainer to update. Seems

If I pin a version of Python, isn't that going to wreck any tooling that depends on it? Unless you're saying have multiple versions of Python installed. This is practically the only remaining annoyance I have with the Python ecosystem (relative imports aside). I use some tools, like Glances [0] whose formula relies on a much newer version (3.12) than the actual package requires (3.8) [1]. So when there's a Python update, all of those update as well. I thought I'd fixed this with pipx, but in a way that's worse, because the venvs it builds depend on a specific version of Python existing, which doesn't work well with brew always wanting to upgrade it. I want a stable, system-level Python that I don't touch, don't add packages to, and which only exists as a dependency for anything that needs it. If an update would break a package I have inst

The user who submitted the bug report was using Homebrew, which does not build curl with the system version of OpenSSL: https://github.com/Homebrew/homebrew-core/blob/547d6bb9b289c...

That behaviour is also a curl configuration option i.e. with-ca-fallback. Curl definitely should be updating man pages if it is falling back to OpenSSL CAs when --cacert is specified. Homebrew Curl on Mac also sets this flag: https://github.com/Homebrew/homebrew-core/blob/9cccce7a6dff7...

> fortune | cowsay Definitely be careful about using fortune in a corporate environment or public space if you don't know what dat files you are using or you might just get an extremely unwelcome surprise. I was practicing a presentation and used to use fortune all the time. I forget exactly what it output but I remember being absolutely mortified about what could have happened if that had popped up during an internal company tech talk. Kudos to brew for keeping unsuspecting people safe https://github.com/Homebrew/homebrew-core/commit/3fb3c4c3e55...

I wrote a tool (chkbit [1]) to verify the data integrety for backups. It's not developer related and so I don't think it will ever get a lot of stars on Github (tbh I am not interested in tracking if anyone is using it at all). Yet when I tried to add this to Homebrew [2] I was rebuffed by their "Stargate" * GitHub repository not notable enough (<30 forks, <30 watchers and <75 stars) I'm sorry to be asking this as I find it a bit silly, but it's blocking my PR [3], so could a few of you star the project on Github [1] to get my PR to run? [1] https://github.com/laktak/chkbit-py [2] https://brew.sh [3] https://github.com/Homebrew/homebrew-core/pull/160018

If you already use homebrew, that works too: https://github.com/Homebrew/homebrew-core/blob/3ef7d3e13549b...