Cannot update on MacOS after homebrew install.

[Tyguy047]

I cannot update to the latest version after I install from home brew. Is Mac OS support discontinued?

[alerque]

You cannot upgrade things installed via homebrew using a 3rd party mechanism like the built in app updater. You need to update it via brew as well, which means waiting until somebody updates the formula.

This goes for all Homebrew installled packages (and is typical of distro packages in most Linux/BSD/etc. systems as well). If you use a package manager to install, use the same one to update.

[thomasdn]

I think the real issue here is that the homebrew package is deprecated (https://formulae.brew.sh/cask/gittyup).
Homebrew only provides version 1.4.
Current version is 2.0.
The official Gittyup website recommends using homebrew to install gittyup: https://murmele.github.io/Gittyup/

I see two possible fixes:

1: Update the homebrew packaged version to current version

or

2: Build a macOS version and release it directly on the Gittyup website or GitHub Releases page.

Personally I would prefer that the homebrew version is updated but I am not sure why it is apparently deprecated and abandoned?

[alerque]

It's marked as deprecated because a they haven't been able to get it building from source properly so that it can live as a regular formula, and it is only running by wrapping the upstream generated dmg image which is Intel only. Hence it has to be run under an emulator on most modern Macs, and they are trying to get away from that (for good reason).

If this project would address some of the issues I've brought up in the past for distro packaging (see e.g. #817) then it should be relatively easy to get a Homebrew formula up to date as well that would actually be a proper build from source on the correct system architecture.

[thomasdn]

Dec 20, 2024 ·

Opened over a year ago 🤨
Seems it is probably not going to happen?

[alerque]

One item got checked off 2 weeks ago (I just checked it but the fix shipped in 2.0.0).

Yes it would be nice if the dev started to prioritize getting off of forked dependencies and making things work with standard build systems then it would open up a whole world of distribution options. Upstream projects trying to build their own packaging only serves a very narrow window of use cases. It isn't just Arch Linux and Homebrew that would benefit from not having to use a forked libgit2 to build — dozens of other distros would become viable if these issues were addressed.

[Tyguy047]

I ended up building it my self and I haven't had any issues on my M1 MacBook Air. If they need a silicon Mac to build I could send over the binary or DMG if that would help?

[alerque]

I think Apple silicon is an option for a runner in GH Actions, but somebody has to set up a build job and test the result. Maybe you could adapt what you did to some actual build steps in a CI job to get a DMG being generated in CI. Once you confirm that works that can be included in the release process or even manually triggered with much more confidence than trusting a 3rd party binary build.

[AHSauge]

One item got checked off 2 weeks ago (I just checked it but the fix shipped in 2.0.0).

Yes it would be nice if the dev started to prioritize getting off of forked dependencies and making things work with standard build systems then it would open up a whole world of distribution options. Upstream projects trying to build their own packaging only serves a very narrow window of use cases. It isn't just Arch Linux and Homebrew that would benefit from not having to use a forked libgit2 to build — dozens of other distros would become viable if these issues were addressed.

In all fairness, this is a whole bunch of technical debt from GitAhead, and not the easiest thing to clean up. I had a look at this at some point to see if I could help push this further in the right direction, and for libgit2 (which is the show-stopper) it's a mixture of flawed API changes, things that (somehow cumbersomely) could be dealt with without requiring changes, and things that look reasonable, but are outright ignored upstream. I poked one PR, and there's really no feedback given at all. So this isn't trivial to solve. It's either a case of removing/bypassing functionality or live with the fork. Getting stuff upstreamed clearly seems to require building trust with upstream.

[AHSauge]

I think Apple silicon is an option for a runner in GH Actions, but somebody has to set up a build job and test the result. Maybe you could adapt what you did to some actual build steps in a CI job to get a DMG being generated in CI. Once you confirm that works that can be included in the release process or even manually triggered with much more confidence than trusting a 3rd party binary build.

This might just be my ignorance, but wouldn't this also implicitly be enough to push for a conversion to a proper formula in homebrew? If they grab the prebuilt binaries, then surely they don't object to the bundling issues.

[Tyguy047]

I think Apple silicon is an option for a runner in GH Actions, but somebody has to set up a build job and test the result. Maybe you could adapt what you did to some actual build steps in a CI job to get a DMG being generated in CI. Once you confirm that works that can be included in the release process or even manually triggered with much more confidence than trusting a 3rd party binary build.

This might just be my ignorance, but wouldn't this also implicitly be enough to push for a conversion to a proper formula in homebrew? If they grab the prebuilt binaries, then surely they don't object to the bundling issues.

From reading a few of the other issues and judging by the fact that there used to be a MacOS release and home brew package, I am guessing that the maintainer used to have a Mac and would build locally. Since there's only Linux releases now they prob daily drive a Linux device now and Mac builds aren't a priority. I don't think they'll want to keep maintain the home brew package but maybe they would merge a PR with an action to build for ARM.

[Murmele]

@Tyguy047 Thanks for trying to build it on Mac. Perhaps I have only Linux I can only test this and building on Mac is only limited over the github ci (which is really anoying). Maybe you could try to get the macos build running again in the ci we can enable it again and then someone can also easily update on brew

You could use this branch as base. It enables all macos artifacts again and adds building openssl again

[Murmele]

One item got checked off 2 weeks ago (I just checked it but the fix shipped in 2.0.0).

Yes it would be nice if the dev started to prioritize getting off of forked dependencies and making things work with standard build systems then it would open up a whole world of distribution options. Upstream projects trying to build their own packaging only serves a very narrow window of use cases. It isn't just Arch Linux and Homebrew that would benefit from not having to use a forked libgit2 to build — dozens of other distros would become viable if these issues were addressed.

We are trying to get an upstream libgit2 version. I changed the code to get rid of the fork used before. Now we have the upstream with a few patches with pullrequests on the libgit2 side (since more than a year now, but nowbody looks on those pullrequests)