Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

regression: all releases after 1.5.121 are not 'universal' for both Intel and ARM/AppleSilicon Macs anymore #3593

Closed
core-code opened this issue Sep 4, 2021 · 72 comments

Comments

@core-code
Copy link

1.5.121 was universal, 1.5.122 is not anymore:

%file /Volumes/balenaEtcher\ 1.5.121-universal/balenaEtcher.app/Contents/MacOS/balenaEtcher

/Volumes/balenaEtcher 1.5.121-universal/balenaEtcher.app/Contents/MacOS/balenaEtcher: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
/Volumes/balenaEtcher 1.5.121-universal/balenaEtcher.app/Contents/MacOS/balenaEtcher (for architecture x86_64):	Mach-O 64-bit executable x86_64
/Volumes/balenaEtcher 1.5.121-universal/balenaEtcher.app/Contents/MacOS/balenaEtcher (for architecture arm64):	Mach-O 64-bit executable arm64


% file /Volumes/balenaEtcher\ 1.5.122/balenaEtcher.app/Contents/MacOS/balenaEtcher          
/Volumes/balenaEtcher 1.5.122/balenaEtcher.app/Contents/MacOS/balenaEtcher: Mach-O 64-bit executable x86_64

@blitzcaster
Copy link

Any news on this? I'm currently stuck at 1.5.121 on MBP M1.

@thundron
Copy link
Contributor

No news yet, see the other issue linked

@core-code core-code changed the title regression: 1.5.122 is not 'universal' for both Intel and ARM/M1/AppleSilicon Macs anymore regression: 1.6.0 is not 'universal' for both Intel and ARM/M1/AppleSilicon Macs anymore Oct 12, 2021
@core-code
Copy link
Author

same with 1.6.0

~ % file balenaEtcher-1.6.0.zip_folder/balenaEtcher.app/Contents/MacOS/balenaEtcher 
balenaEtcher-1.6.0.zip_folder//balenaEtcher.app/Contents/MacOS/balenaEtcher: Mach-O 64-bit executable x86_64
~ % file /Volumes/balenaEtcher\ 1.6.0/balenaEtcher.app/Contents/MacOS/balenaEtcher 
/Volumes/balenaEtcher 1.6.0/balenaEtcher.app/Contents/MacOS/balenaEtcher: Mach-O 64-bit executable x86_64

@thundron
Copy link
Contributor

@core-code does it still open without emulation as some users reported?

@core-code
Copy link
Author

@thundron i don't have any ARM Macs to test this. but i fail to see how a binary that only contains Intel code would run without emulation on ARM...

@btwise
Copy link

btwise commented Oct 15, 2021

The script with universal parameter should be added to the Makefile

@core-code
Copy link
Author

issue persists in 1.7.0

@core-code core-code changed the title regression: 1.6.0 is not 'universal' for both Intel and ARM/M1/AppleSilicon Macs anymore regression: 1.7.0 is not 'universal' for both Intel and ARM/M1/AppleSilicon Macs anymore Nov 11, 2021
@n0rt0nthec4t
Copy link

Add me to the issue,, when can we expect to have a universal binary back?!>?!?

@danielktdoranie
Copy link

danielktdoranie commented Nov 24, 2021

Add me to the issue,, when can we expect to have a universal binary back?!>?!?

Same here I can confirm that 1.7.0, as downloaded from https://www.balena.io/etcher/ STILL requires Rosetta 2 to work and is NOT Apple Silicon/M1 native.

What's the deal here? I understand we had native Apple Silicon support with Version 1.5.121 (1.5.121) support and then it was removed? Why?!

When will it be back?

@nodesocket
Copy link

Also echoing why native Apple Silicon (Universal) support was lost? Running latest version of Etcher 1.7.1 (1.7.1).

MacBook-Pro ➜ pwd
/Applications/balenaEtcher.app/Contents/MacOS

MacBook-Pro ➜ file balenaEtcher
balenaEtcher: Mach-O 64-bit executable x86_64

@fishcharlie
Copy link

@thundron Any chance you could please provide a status update here? 😃

@thundron
Copy link
Contributor

thundron commented Dec 8, 2021

@fishcharlie sure! unfortunately there's not much information yet that we can safely point to as the root cause; there have been some changes to our CI system, but none of those changes should've impacted the universal build in any shape or form; moreover, there have been some dependencies updates but again, none of those dependencies/changes were pertaining to the macOS universal package, or the package build at all (if not for how dependencies are packed), so we're still investigating!

@fishcharlie
Copy link

@thundron Thanks for the update.

I decided to look into this a little bit, and compared the versions between v1.5.121...v1.5.122.

The only thing that stands out is the resin submodule update: product-os/scripts@d1b05ad...8dfa21c. Everything else looks completely unrelated to this issue.

So I dug into those changes. The thing that stands out to me is if you search for platforms on that page, I see a lot of changes related to that within the docker/build.sh file. Is that related? Maybe the platforms are excluding Apple Silicon, where before it was undefined so it would build for all platforms? No idea. All questions that I think are above my head at this point, and without digging into why those changes were made, and what some of those variables are set to, it's difficult to know why things are failing.

Makes me wonder if reverting that submodule update and attempting again, would produce an Apple Silicon build. That would at least narrow things down. But that raises other questions that I'm not sure about, such as: were there behind the scene changes to the CI system where these submodule changes are required now?

I might try to dig into this a bit deeper later on and try to run some of the things myself. But I'm pretty unfamiliar with the CI system here. Loading https://ci.product-os.io/builds/95676, produces a spinning Loading page that never completes. But that doesn't even look like a recent deployment build necessarily.

However, it sounds like @thundron probably has a lot more context here about what is going on than I do. So I'm not sure me spinning my wheels on it will produce a solid outcome and solve the issue.

Wish I could help more. Really want to support the open source community and get this resolved for everyone (and myself 😉). But @thundron if there is anything else I can do to support this effort, please let me know. Would be happy to try to run some of this locally and debug further, but might need some support in getting pointed in the right direction to get that setup.

@thedocbwarren
Copy link

Simple solution could be to publish two builds for now (also on homebrew.)

@n0rt0nthec4t
Copy link

1.73 and STILL no universal binary..

@robd003
Copy link

robd003 commented Jan 7, 2022

@fishcharlie sure! unfortunately there's not much information yet that we can safely point to as the root cause; there have been some changes to our CI system, but none of those changes should've impacted the universal build in any shape or form; moreover, there have been some dependencies updates but again, none of those dependencies/changes were pertaining to the macOS universal package, or the package build at all (if not for how dependencies are packed), so we're still investigating!

@thundron Could you share the CI build configuration? I think there's enough motivated people here to get it working again if we can get the details.

@danielktdoranie
Copy link

Okay, so still no Native support of Apple Silicon? We had working Apple Silicon support in 1.5.121... what happened? Why was this dropped?

@fishcharlie
Copy link

@danielktdoranie Wasn't dropped intentionally. See the previous comments. @thundron mentioned that although some CI changes were made, nothing should have impacted Apple Silicon support. Although clearly something did.

I posted a summary of some work I did to pinpoint the issue above.

All of your questions have been previously answered in this thread tho.

@danielktdoranie
Copy link

@danielktdoranie Wasn't dropped intentionally. See the previous comments. @thundron mentioned that although some CI changes were made, nothing should have impacted Apple Silicon support. Although clearly something did.

I posted a summary of some work I did to pinpoint the issue above.

All of your questions have been previously answered in this thread tho.

And yet we are still without native Apple Silicon support. Last post was over a month ago.

Intel Macs aren’t being made any longer so any Intel code for Macs at this point is by definition legacy support.

Instead of trying to figure out why the universal binary doesn’t work, why not just release an arm64 Mac version on the Releases page?

@fishcharlie
Copy link

@danielktdoranie

Last post was over a month ago.

Kinda hard to say this when a LOT of people take a lot of time off during December...

Intel Macs aren’t being made any longer so any Intel code for Macs at this point is by definition legacy support.

This is categorically false. Just because Apple hasn't released any new Intel Macs, doesn't mean they aren't being made any longer. Intel Macs are still being manufactured to this day. And more importantly remain for sale from Apple.

Instead of trying to figure out why the universal binary doesn’t work, why not just release an arm64 Mac version on the Releases page?

Making an educated guess here. The amount of effort that would require would likely be just as substantial as fixing the issue.


Remember. This is open source software. Normally I'd be very sympathetic to your case. Pushing companies to stay current with technology is critical.

However, it is open source. You can go and create your own build for native support just fine. No issues. In fact I've done that myself.

Or you can spend the time required working to fix or pinpoint the issue yourself.

It's not like this project has seen a lot of major updates recently and this is just on the back burner. It clearly looks like a resources issue, not a priority issue. Which makes complaining about it unproductive.

@danielktdoranie
Copy link

The Mac Pros are the only Intel Macs left and they’ll be replaced with an M1 counterpart soon enough, even Apple said themselves that they will transition to Apple Silicon completely with in 2 years, and we are only a few months out from that. Also that Mac Pro design was released in December 2019: so yeah as NO NEW Intel macs are being released Intel Mac code is is de facto legacy support.

My comments are no more “unproductive” than your’s: Take your own advice.

@nodesocket
Copy link

nodesocket commented Jan 19, 2022

Ok, gentlemen let’s stop the petty bickering. However, Intel Macs are basically end of life and Apple did say it would be a two year transition to Apple Silicon which looks more like three years now. Apple Silicon support is a must have, since I suspect Apple will be sunsetting Rosetta 2 shortly.

Let’s focus on getting the universal binary build working again instead of adding complexity for a dedicated arm64 build.

It should be fairly straightforward to git blame and go line-by-line. Also, look at the 3rd party build tooling to see if they changed any API’s or anything. My concern is perhaps this is not a regression, but intentional. Seems suspicious a regression would remove universal binary support and go unfixed for months. Perhaps running universal binary blocks something balena is currently doing (telemetry) or worse???? I’ll admit my theory is completely unfounded though.

@danielktdoranie
Copy link

danielktdoranie commented Jan 19, 2022

Let’s focus on getting the universal binary build working again instead of adding complexity for a dedicated arm64 build.

I understand that ultimately that is the best solution for legacy Intel Mac users as well as Apple Silicon users, my thinking was if a stop-gap Apple Silicon native only build could be complied and put on the releases page it would help Apple Silicon users like myself… given we are months in at this stage.

I’d be happy for either a native or universal binary, just don’t want to run Rosetta 2. It’s a memory and battery hog. I have removed it from all of my Apple Silicon Macs.

@thedocbwarren
Copy link

Let’s focus on getting the universal binary build working again instead of adding complexity for a dedicated arm64 build.

I understand that ultimately that is the best solution for legacy Intel Mac users as well as Apple Silicon users, my thinking was if a stop-gap Apple Silicon native only build could be complied and put on the releases page it would help Apple Silicon users like myself… given we are months in at this stage.

I’d be happy for either a native or universal binary, just don’t want to run Rosetta 2. It’s a memory and battery hog. I have removed it from all of my Apple Silicon Macs.

I'd be happy to be able to compile myself if the procedure were available.

@robd003
Copy link

robd003 commented Mar 19, 2022

@thedocbwarren Awesome! Downloading it now, I'll let you know how it goes.

@robd003
Copy link

robd003 commented Mar 19, 2022

@thedocbwarren Unfortunately I'm getting the same error.

However if you manually run xattr -rc /Applications/balenaEtcher.app then it'll work.

@thedocbwarren
Copy link

Ok, I'll work on this. I think it's signing. I promise I'll fix this.

@thedocbwarren
Copy link

Signing complete. Release 1.7.8 is now signed.

@thedocbwarren
Copy link

There appears to be an issue with webpack for mac and linux on arm for 1.7.9. I'm investigating. The build succeed but no output of DMG or AppImage is created.

@thedocbwarren
Copy link

Confirmed, no build produces a package despite successful compile. Tried on x64 as well.

@mcraa
Copy link
Contributor

mcraa commented Apr 23, 2022

Strange @thedocbwarren, there were no changes effecting the mac build.
Only the fix for .deb install.
At the same time it means not having 1.7.9 on mac won't make any mac user miss out on anything, it should be identical to 1.7.8

@thedocbwarren
Copy link

Strange @thedocbwarren, there were no changes effecting the mac build. Only the fix for .deb install. At the same time it means not having 1.7.9 on mac won't make any mac user miss out on anything, it should be identical to 1.7.8

I saw that. I'll keep on it and see what could be causing it. I'll check with Debian as well to see what could be the cause. I reviewed the webpack config and didn't see anything that prevents the dist folder from getting created or updated for output.

@thedocbwarren
Copy link

Strange @thedocbwarren, there were no changes effecting the mac build. Only the fix for .deb install. At the same time it means not having 1.7.9 on mac won't make any mac user miss out on anything, it should be identical to 1.7.8

Ok, confirmed Debian does not output anything as well.

@thedocbwarren
Copy link

Strange @thedocbwarren, there were no changes effecting the mac build. Only the fix for .deb install. At the same time it means not having 1.7.9 on mac won't make any mac user miss out on anything, it should be identical to 1.7.8

I am unable to find where the issue is. Something may be different in the output process -or- something is going wrong in webpack's config to not produce a 'dist' folder. I'm less concerned about 1.7.9, as stated, doesn't do much for non-deb platforms but more for 1.7.10 or later.

@core-code core-code changed the title regression: 1.7.0 is not 'universal' for both Intel and ARM/M1/AppleSilicon Macs anymore regression: all releases after 1.5.121 are not 'universal' for both Intel and ARM/M1/AppleSilicon Macs anymore Oct 10, 2022
@core-code core-code changed the title regression: all releases after 1.5.121 are not 'universal' for both Intel and ARM/M1/AppleSilicon Macs anymore regression: all releases after 1.5.121 are not 'universal' for both Intel and ARM/AppleSilicon Macs anymore Oct 10, 2022
@thedocbwarren
Copy link

1.7.12 builds fine for MacOS ARM, however like before the build script does not generate a DMG. Could I get new instructions for how to build this correctly?

@nodesocket
Copy link

Just installed the latest version 1.7.15 on macOS Ventura, but same thing. Running as intel emulated via Rosetta.

Screenshot 2022-11-07 at 4 51 28 PM

@thedocbwarren
Copy link

Yes, @nodesocket it needs a native build. I'll wait for the release storm to finish and I'll try again to build.

@thedocbwarren
Copy link

1.10.0 builds, but produces no package (DMG.) Not sure how to produce to publish a community build for Apple Silicon.

@lurch
Copy link
Contributor

lurch commented Nov 16, 2022

Looks like https://github.com/balena-io/etcher/blob/master/.github/actions/publish/action.yml#L173 might be where the magic happens?

@thedocbwarren
Copy link

@lurch What I can see with this (maybe wrong) is it's using GitHub actions to build that, meaning local builds won't produce a DMG. This seemed to be true from 1.7.9 on. I can launch via CLI to run the electron app but not install it. If this is true, I can't build a DMG to publish and they will have to build this officially in their CI.

@thedocbwarren
Copy link

I want to add, I saw somewhere those actions are x64 only so that is an issue for ARM. But just to mention, this is open-source and not being able to build and install kind of breaks that and should be corrected. Unless the new procedure is to create a start script and build and run from npm I suppose.

@thedocbwarren
Copy link

I have been able to compile recently but no DMG is built. Is GitHub actions the only way to build a DMG with the codebase?

@donluca
Copy link

donluca commented May 22, 2023

  • Install Xcode
  • Git clone this repo
  • npm i
  • Check if all native modules “node-gyp”-ed correctly ... If not go to the folder of the module (inside node_modules) and run electron-rebuild
  • npm run webpack
  • ./node_modules/.bin/electron-builder
  • (no additional parameters are needed, as you are running on the target architecture)
  • You output .dmg file will be located in the dist folder

I'm trying to build an arm64 native build, but I'm encountering this error after doing ./node_modules/.bin/electron-builder :

⨯ The appleIdPassword property is required when using notarization with appleId failedTask=build stackTrace=Error: The appleIdPassword property is required when using notarization with appleId

I don't care about distributing it, I just want it for myself, how can I tell electron to skip notarization?

EDIT: nevermind, I managed to disable notarization myself. Build working correctly on a Mac Mini M2 with macOS Ventura 13.4

@thedocbwarren
Copy link

thedocbwarren commented Jul 12, 2023

Getting the same error but I can sign with my Developer ID if possible. What is the procedure? I can start building the community Apple Silicon builds again.

@dfunckt
Copy link
Member

dfunckt commented Jul 13, 2023

Closing in favor of #3728

@dfunckt dfunckt closed this as completed Jul 13, 2023
@JordanIdler
Copy link

JordanIdler commented Jul 28, 2023

Getting the same error but I can sign with my Developer ID if possible. What is the procedure? I can start building the community Apple Silicon builds again.

afterSignHook.js shows it, you need to set these env variables.

if (electronPlatformName !== 'darwin' || ELECTRON_SKIP_NOTARIZATION === 'true') {
    return
 }

  const appName = context.packager.appInfo.productFilename
  const appleId = process.env.XCODE_APP_LOADER_EMAIL || 'accounts+apple@balena.io'
  const appleIdPassword = process.env.XCODE_APP_LOADER_PASSWORD

So:
export ELECTRON_SKIP_NOTARIZATION=true

@thedocbwarren
Copy link

thedocbwarren commented Jul 28, 2023

The problem with that is, I want to sign so I can make community builds on macOS for Apple Silicon. If this has to be signed by Balena, than that's game over for Apple Silicon native till they make it happen.

@JordanIdler
Copy link

The problem with that is, I want to sign so I can make community builds on macOS for Apple Silicon. If this has to be signed by Balena, than that's game over for Apple Silicon native till they make it happen.

If you look at the code snip-it I provided. You can leave it as true, and provide process.env.XCODE_APP_LOADER_PASSWORD and process.env.XCODE_APP_LOADER_EMAIL if you wish to sign it

@robd003
Copy link

robd003 commented Jul 30, 2023

Why is Balena incapable of building & signing either Universal binaries of Etcher or building x86_64 AND arm64 builds?

@thedocbwarren
Copy link

Going to give this another try and try to build a signed Apple Silicon build.

@matthewyang204
Copy link

I've tried to build an Apple Silicon version of the latest release, it keeps on spitting out errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests