ci: Bring back x86_64 Release #217
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Qian Qian "Cubik" <[email protected]>
Signed-off-by: Qian Qian "Cubik" <[email protected]>
Signed-off-by: Qian Qian "Cubik" <[email protected]>
Signed-off-by: Qian Qian "Cubik" <[email protected]>
This would also allow us to build x86_64 binaries on arm64 Macs, as, on Mac with Rosetta 2 installed, `/usr/bin/arch -x86_64 /bin/zsh ./build.sh` will change the environment used to run the script and make uname report x86_64. Signed-off-by: Qian Qian "Cubik" <[email protected]>
Signed-off-by: Qian Qian "Cubik" <[email protected]>
Signed-off-by: Qian Qian "Cubik" <[email protected]>
Signed-off-by: Qian Qian "Cubik" <[email protected]>
…ipt (prepare for x86_64) Signed-off-by: Qian Qian "Cubik" <[email protected]>
Signed-off-by: Qian Qian "Cubik" <[email protected]>
Signed-off-by: Qian Qian "Cubik" <[email protected]>
Signed-off-by: Qian Qian "Cubik" <[email protected]>
Signed-off-by: Qian Qian "Cubik" <[email protected]>
Signed-off-by: Qian Qian "Cubik" <[email protected]>
This should prevent exit code `124` of the `timeout` from failing the build job. Signed-off-by: Qian Qian "Cubik" <[email protected]>
This prevent timeout from failing the build workflow. Signed-off-by: Qian Qian "Cubik" <[email protected]>
Signed-off-by: Qian Qian "Cubik" <[email protected]>
|
/cc @PF4Public @networkException I want this to be sorted out before I update the version again... |
|
Any updates on the content of this PR? /cc @networkException @PF4Public @ungoogled-software/macos |
networkException
approved these changes
Jan 16, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
There's no Intel builds for Ungoogled Chromium macOS since https://github.com/ungoogled-software/ungoogled-chromium-macos/releases/tag/131.0.6778.85-1.1. For more information, see (#216). In a nutshell, it is because Google took advantage of the new macOS 15 SDK since Chromium 131, and GitHub is not providing macOS 15 Free Action runners on Intel platform, which prevented our release workflow (that builds x86_64 and arm64 binaries on their native runner respectively) from running properly.
Solution
Back in the early days, arm64 binaries were also built on x86_64 host, which is officially supported and pretty well documented. However, there are nearly no up-to-date enough info to directly build x86_64 binaries on arm hosts.
This pull request contains the workaround of using Rosetta 2 (Apple's x86_64 to arm64 translator) to build the x86_64 binary in essentially an "emulated" x86_64 environment.
/usr/bin/arch -x86_64 /bin/bashis used to switch the shell to Rosetta environment, then x86_64 Homebrew is installed to install x86_64 version of dependencies (Python, Ninja, etc.), and Ungoogled Chromium is built with those.On local environment,
"$(/usr/bin/uname -m)"which will be changed based on architecture assigned to script using/usr/bin/archwill be used to decide which platform to build for.On GitHub Action, both
unameand the workflow input is used depending on wether/usr/bin/archis needed to run a certain script in Rosetta environment and if directly passing the value as a script parameter will be easier and play nicer with the GitHub Action flow./usr/bin/archis probably not needed everywhere where it is right now, but I did put it everywhere where it might needed to be to guarantee this works.One of the biggest problem of this solution is that it takes more than an entire day to build this on GitHub Action and release, but I don't have a better solution for this now.
TODO:
Signed-off-by: Qian Qian "Cubik" [email protected]