Posted by sneak on 2024-12-31.

I’m offering $500 in bitcoin or ethereum to anyone who fixes the macOS build process.

I’ll also reimburse you up to another $500 for the cost of a mac development system (with proof of purchase) if you need to get one (but I’d hope that you’d use it to keep the build working for some time, like a few months or something).

Binary signing is not required; it’s common for free software (especially nightlies) to not be signed. An apple developer subscription is not required to claim this bounty.

Replies

sneak — 2024-12-31

To claim the bounty, contact me at sneak@sneak.berlin.

Aurélien Pierre — 2025-01-01

The problem of “fixing” CI/nightly builds is whatever you fix is only going to be temporary. It’s the same issue for Windows (using Arch Linux repositories through MSYS2 and Pacman) and MacOS (using Brew or Macports repositories) : they are rolling-release, so the packages are always built with the last version of third-party libraries, which may deprecate API, force versions bumps for CMake, C/C++, Clang, GCC, etc. possibly clashing with our owns configs, all that without prior notice (unless you subscribe to all mailing-lists around, spend time reading all news, etc. – Not really feasible, if you ask me). For MacOS, there is also the matter of ARM-based and x86_64-based variants to support, that depends on the host system used to build packages (and have their own set of issues with third-party libs).

So, I’m more and more leaning towards building static Windows and Mac disk images, shipping static versions of libraries (that will not be updated before each build), so we know they work until someone manually updates the images when enough time is available to troubleshoot. Because, right now, stuff breaks out of any schedule and we just wake up with new problems, but not necessarily time to fix them again. It’s not only time-consuming, it’s overwhelming, unglamourous and verging on depressing.

Now, the problem is Github Actions don’t allow to use static disk images, so that would mean deferring the build to something Amazon Elastic Cloud 2, and then firing the EC2 instance from Github, building, sending the packages back to Github. That’s the most future-proof approach I can think of, instead of shoveling shit on a random basis, but it’s going to cost money to run the EC2 instances and a lot of time to wire and debug everything.

TL;DR: fixing Win/MacOS builds now and for the few next weeks is no “big” issue. Committing to shoveling shit again and again as things unexpectedly break in the future is the real issue here.

cendalc — 2025-01-01

I run Ansel on Window so it’s a pity for me the latest builds are not available. I very much understand your pain with rolling-releases - it’s crazy to maintain with because you have no reproducibility.

I tried to look into the possible solutions (although I have no experience with MSYS2, Pacman, C/C++, …) and I think either hosting tool versions in custom Pacman repository or creating a docker container with all tools could be a solution - probably docker being simpler solution. The disadvantage is longer build time and probably cost with downloading the docker image every day…

Translated from English by : Aurélien Pierre, ChatGPT, Claude, Claude (Anthropic). In case of conflict, inconsistency or error, the English version shall prevail.