ci: Use macOS 15 to build

[Cubik65536]

Chromium changed a lot of things since version 131 to take advantage of macOS 15 SDK, like [5894764] (also see ungoogled-software/ungoogled-chromium#3089 (comment)) and [5868514] (also see https://github.com/ungoogled-software/ungoogled-chromium-macos/actions/runs/11963693332).

As a consequence, our GitHub Action Host, running macOS 13 (for Intel) and 14 (for ARM), aren't able to build new versions. As it might be too much of hassle to revert all changes, and I actually expect more changes to come, I decided to move to macOS 15 Action Runner for both platforms.

Potential downsides are:

• macos-15 runner is in public preview state for GitHub Action, so it might be unstable;
• compatibility with older macOS version might not be as great;
• as there's no Intel runner with macOS 13+, we have to cross compile x64 ungoogled-chromium from ARM hosts, which might make the now ages long building action even longer (or shorter, we shall see, ARM might be still faster).

But this is the best solution I can come up with for now.

Current Test Run: https://github.com/iXORTech/ungoogled-chromium-macos/actions/runs/11984866059 (the 7th one, let's hope it pass)

Signed-off-by: Qian Qian "Cubik"‎ <[email protected]>

[Cubik65536]

Update: arm64 builds fine, still need to fix x64 build.

[Cubik65536]

There's still issue building for x86_64 on arm64 (Rust is the most apparent one now), and referring to https://chromium.googlesource.com/chromium/src.git/+/master/docs/mac_arm64.md#building-on-arm-macs (and https://issues.chromium.org/issues/40209129), I will disable Intel (x86_64) build for now, until we have a better solution (our own building hosts, or some other patches). This is the best solution I can get, given that I don't have much time to work on this.

/cc @PF4Public @networkException

[PF4Public]

There's still issue building for x86_64 on arm64

I'm just curious why cannot you build not on arm?

I'm also hesitant about or for me to cover some of my personal expenses. @networkException would this be a good wording?

[Cubik65536]

There's still issue building for x86_64 on arm64

I'm just curious why cannot you build not on arm?

I do not have a machine on Intel, and GitHub Action do not have Intel hosts with newer macOS. And the root cause of the whole issue is that Chromium took advantage of newer SDK and basically making it impossible to build with older OS.

I really cannot afford the time needed to add a patch, wait 1 hour or more for GitHub Action to maybe give a new error and then go back do a new patch, considering those changes are rather big (refer to the commits I put in the PR description).

I'm also hesitant about or for me to cover some of my personal expenses. @networkException would this be a good wording?

I am also rethinking about that, I might remove it, it is there for transparency at first (I want to tell where those contributions go if not Apple Developer License).

[PF4Public]

basically making it impossible to build with older OS

You're the maintainer, so it is up to you what is best :)

I want to tell where those contributions go if not Apple Developer License

I would suggest thinking of it this way: if it was stated to be used for Apple Certificate at the first place (at the time of donation taking place), it should be used for just that. Changing the donation target afterwards might be a moral problem at the very least.

[Cubik65536]

basically making it impossible to build with older OS

You're the maintainer, so it is up to you what is best :)

I will investigate what I can do when I have more time, I just don't have that much time now.

I want to tell where those contributions go if not Apple Developer License

I would suggest thinking of it this way: if it was stated to be used for Apple Certificate at the first place (at the time of donation taking place), it should be used for just that. Changing the donation target afterwards might be a moral problem at the very least.

Yeah, I agree with that, I'll change it.

[PF4Public]

You removed "future membership years" too :)

[Cubik65536]

You removed "future membership years" too :)

It was because the list contained the sponsors who's contribution that was not counted towards this year's license fee, now that all contributions is only for Apple License, the list will just be updated based on the year and all contributions from the people on the list will only be for this year's Apple License.

[Cubik65536]

You removed "future membership years" too :)

It was because the list contained the sponsors who's contribution that was not counted towards this year's license fee, now that all contributions is only for Apple License, the list will just be updated based on the year and all contributions from the people on the list will only be for this year's Apple License.

More on that, I might have to come up with some other ways to sort this out. My initial idea is just asking for some sponsor help, and I'll make sure that no matter what, the current and the next year's Apple License should be secured first, and then I might reallocate these for other purpose. This was because UGC is not the only source of sponsor (even though I absolutely know it made the very most part of it), and I couldn't possibly mark every sponsor as Apple License only in a long term...

[PF4Public]

My initial idea is just asking for some sponsor help, […] and then I might reallocate these for other purpose.

In no way I'm saying that you cannot do that. I wanted to convey that it would be the fairest if you would clearly and transparently state your intention first and then act accordingly having the approval of your donors.

[Cubik65536]

My initial idea is just asking for some sponsor help, […] and then I might reallocate these for other purpose.

In no way I'm saying that you cannot do that. I wanted to convey that it would be the fairest if you would clearly and transparently state your intention first and then act accordingly having the approval of your donors.

This is the idea when I first started the donation project and still is, and I agree that this is not clearly communicated, and it's me to blame for that. The plan now is that I will make sure all previous contributions is for the Apple Developer License, and then I will make this clear in the both the issue and the related README section so it's acknowledged by all future sponsors. Does this sound like a good plan to deal with this?

[PF4Public]

I will make this clear in the both the issue and the related README section so it's acknowledged by all future sponsors. Does this sound like a good plan to deal with this?

Absolutely!

[Cubik65536]

I will make this clear in the both the issue and the related README section so it's acknowledged by all future sponsors. Does this sound like a good plan to deal with this?

Absolutely!

I plan to add this note to #184 and the sponsorship section of the README/Announcement:

Note

The prioritized usage of the sponsorship contribution will always be the coverage/securing the Apple Developer Membership fee of the current and the following membership year. However, please acknowledge that, after the current and the next year's membership fees have been fully covered/secured, any donation I receive might be reallocated for other personal purpose.

Does this sound good as a clarification for this? /cc @PF4Public @networkException

[Cubik65536]

I added the note above regarding sponsorship to the README, and I'll add it to #184 after this PR is merged, in case we still want to change some detail about it. More importantly, let's publish the 131.0.6778.85 update :)

[PF4Public]

@networkException ?

[networkException]

Thanks!