Octave 8.x and macOS 11+ support (main ticket) #243
Comments
apjanke
added
bug
|
Hey, I got a (buggy) 8.3.0 build running to completion and launching! Getting this error spam about icon files in the command window as soon as it launches. Gotta fix that; it's unusable with this happening.
And huh: the same error message is happening for me in the regular Homebrewed Octave 8.3.0, too, so this may not be specific to Octave.app. But I'll need to get it fixed anyway for this to be usable.
Both of these were on monty-p, a macOS 12.7.1 Monterey VM on an Intel iMac. |
|
I posted an early-preview 8.3.0_alpha1 build on GitHub, built on monty-p a couple days ago running macOS 12.7.1 and Xcode 14.2. This build was running for me on monty-p (with the above "NSWorkspace iconForFile not a full path" error), using my initial build and when I had installed it from the local DMG file (I think). Sebastian reports that it is not working for him: "package is broken" error message when double-clicking the app icon or launching the AppleScript launcher file, but running the To try to reproduce, I downloaded the DMG from the GitHub release page to monty-p and angharad (macOS 14.1). On angharad, "damaged" error: 
And running the binary directly works: That got me a running GUI, and no "iconForFile not a full path" error during my testing. Launching the re-downloaded and re-installed Octave-8.3.0_alpha1 on monty-p took a while to launch (with no splash screen or progress indicators), and then the same "damaged" message:
I reinstalled from a local copy of my local DMG on monty-p (Ctrl-C, Ctrl-V from build/ to Downloads/, then open it and drag to install). Same SHA sum. That worked: the app launched and I got the Octave GUI, no error messages. Weird: same SHA256 sums for my local DMG (that works), both in the original build location and the ~/Downloads/from/local-build copy I made and installed from just now, and my download from GitHub. I copied the DMG from monty-p to angharad using Parallel's "shared folders" feature, Ctrl-C Ctrl-V inside monty to the Shared Folders there in Finder. That worked fine too. Doing a right-click, Open instead of double-clicking in monty-p also gives the "is damaged" error. Okay, time to maybe learn more about exactly how DMGs work, and how binary artifact uploads to GitHub work, and how macOS deals with downloaded files and taint flags stuff there. Maybe I actually did need the "internet-enable" thing in create_dmg?
|
|
I can confirm that when launching the new alpha release I receive the error shown. |
|
HNY, any news, plans on further updates on this development in 2024? |
Yeah, @AppsPackG! Work at my day job has finally let up a bit, so I'm making a big push to get a working Octave.app 8.x build out in the next couple weeks.
What's MacAdmins? I'm not familiar with it, and getting several different hits when I google it. |
|
Rats. I built a new 8.4.0 alpha1 build, carefully uploaded it to GitHub Releases, and got the same behavior as before. I think this is in fact a file hosting problem. After downloading the DMG from GitHub Releases to a macOS 14 VM on eilonwy (Apple Silicon), ran the app and: 
Looks the same as last time: same shasums for the DMGs copied locally and downloaded from GitHub. The app from the local-copied DMG launches, and seems to work (does plotting and runs the test suite). Made a separate issue for this, since it's a distinct problem, and a big blocker, and I don't want to spam this main "8.x" ticket with a bunch of detailed comments about it.l: #244. This is the top issue now, and what I'll be focusing on next. |
|
Got a workaround for you, @AppsPackG, if you want to just test the app. After installing, do I realize this isn't great for packagers (or users for that matter); I'm working on a better fix, or getting app signing working. |
apjanke
changed the title
|
Did some more experimenting and research, and made a couple more alpha builds. (alpha2, alpha3.) Same issue. It looks like this is just how the macOS interface presents its refusal to run an unsigned app that was downloaded from the internet, not that there's some corruption or error in the app build. And that's consistent with the The simpler workaround of doing I don't know if I'll be able to find a better fix than this, short of actually getting app signing working, which has proven difficult in the past. I'm eager to get an 8.x release out and in to users' hands, so I'm not going to call this a blocker, and just put a Special Installation Instructions with a "please do |
|
Uh oh: 
UPDATE: Okay, fixed in octave-app/octave-app-bundler@6488c03. Andrew, you dumbass. Doing another beta1 build now. |
Potentially not an issue, if this DMG is extracted for the purpose of building a pkg from the App using AppPkgCreator processor and uploading to Jamf with Autopkg. |
|
I'm now doing the AS build on a different machine, scone, and I'm getting some "permission denied" errors during the DMG creation. In the I do not know what's going on here. Made a separate ticket for this: #252 |
|
UPDATE: Broke this linear-algebra/logm.m test failure out to separate ticket #256. Hmm. Got a new test failure. Normally I see 2 test failures in I see this one in the scrollback in the command window. Dunno if it's the new one. I'm guessing it is, because it's the only one that says "regression", and I don't remember seeing that recently? In fntests.log, I see: UPDATE: Might only be on AS. I freshened my build on Intel Mac angharad, ran the tests, and got only two failures, both in 
|
|
About the
Hopefully this works there, since it doesn't require Oddly, the quarantining doesn't seem to happen when I download an old release like 4.4.1 from GitHub Releases at https://github.com/octave-app/octave-app/releases/tag/v4.4.1-u1. No idea why. I would have thought it would apply to all new downloads of unsigned apps on newer macOS versions. I'm still trying to get the app signed, and making that higher priority since this problem is happening, but I'm not optimistic, since I was never able to get it to work before even with a fair amount of trying. |
|
[like] BEAUMONT Graham reacted to your message:
…________________________________
From: Andrew Janke ***@***.***>
Sent: Friday, February 2, 2024 10:14:15 PM
To: octave-app/octave-app ***@***.***>
Cc: BEAUMONT Graham ***@***.***>; Mention ***@***.***>
Subject: Re: [octave-app/octave-app] Octave 8.x and macOS 11+ support (main ticket) (Issue #243)
You don't often get email from ***@***.*** Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
About the xattr -c quarantine hack:
Potentially not an issue, if this DMG is extracted for the purpose of building a pkg from the App using AppPkgCreator processor and uploading to Jamf with Autopkg.
Hopefully this works there, since it doesn't require sudo rights. If it doesn't, let me know and i'll try to find a workaround. (E.g. like publish it to a git repo using LFS and you could fetch with git clone, which I think doesn't get hit with the quarantine flag.) I'm going to do the 8.4.0 release soon even if this isn't fixed, so you'll have a "real" release to try it on.
Oddly, the quarantining doesn't seem to happen when I download an old release like 4.4.1 from GitHub Releases at https://github.com/octave-app/octave-app/releases/tag/v4.4.1-u1. No idea why. I would have thought it would apply to all new downloads of unsigned apps on newer macOS versions.
I'm still trying to get the app signed, and making that higher priority since this problem is happening, but I'm not optimistic, since I was never able to get it to work before even with a fair amount of trying.
—
Reply to this email directly, view it on GitHub<#243 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AZYO3VFRANWMZWNQRWSBEGLYRVQLPAVCNFSM6AAAAAA6WUGO3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRUG43TSNJRGM>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
Sopra Steria is the trading name of the following companies (all registered in England & Wales): (i) Sopra Steria Limited (No. 04077975) (ii) Sopra Group Ltd (No. 01643041) (iii) Sopra Group Holding Ltd (No. 01588948)
|
Well I've put an Autopkg solution together for the latest beta release albeit the app name is not as it will end up (I noticed it wasn't happy with me renaming it back to Octave.app). It extracts the application from the DMG and then packages it up with the standard bundle of processors (AppPkgCreator seems to hang, although could be my impatience seeing as it's a 3gb app I wanted to see PkgRootCreater / Copier & PkgCreator processors progress along the way) I had to play around with the mode settings in the package using 755 rather than 775 for the pkgroot location, however when delivered it does launch without error. In order to use a completed app, we would need the app signed so that the CodeSignVerifier processor can use the equivilient pkgutil command before we use it in production environments. I would also ask that the Apple Silicon dmg file is given a suffix like arm64 to mirror the Intel naming standard rather than omitting a suffix please. |
|
Good to hear it's at least kind of working.
Yeah, unfortunately, you can't rename the Octave.app bundles, or run them from anywhere except /Applications, due to how they are built on top of a Homebrew installation. The full path to the app bundle's default location at
Oof da. I'd like to sign the app, but I'm afraid I've had a hard time getting it working. See #83. It's the next big thing I'll be working on after the Octave 9.x release, because the unsigned app is a pain. No idea how likely I'll be successful. But if I can get it code-signed, then I think this whole problem with quarantining and the
I think I could do that. I'd like to keep a suffix out of the main download, since Octave.app is aimed at less-technical users and "-arm64" sounds techie and intimidating. But I think I could just publish a renamed copy of the AS DMG with a "-arm64" suffix in its file name. Or build both. Does it matter to you what the volume name inside the DMG is? |
Thanks for the response. I understand these being beta's that the app will be named in a certain way, but as you say when it's finalised it will revert to Octave.app (Ideally not Octave-8.4.0.app as seen in earlier v6 releases as that isn't normal naming standards from what I see of other macOS apps). The DMG suffix is just to help identify the two different architectures listed in the Github releases, as you already have one with a suffix of Intel. Appreciate you don't want the app named with the architecture types though. |
Okay, say more about this, if you want? My motivations for the current naming are:
I'm not up for naming the app just "Octave.app", because I at least want to support side-by-side installations and executions of different major versions. I'm kinda limited here by the fact that the whole build apparatus for Octave.app is kind of a big hack built on top of Homebrew, and it uses a bunch of packages that basically think they're running on Linux, instead of being a true "native Mac app" build. Ideally, I think I'm with you - the app should be named "Octave.app", and then advanced users can rename it if they want to have side-by-side installs. Buuut due to the hacky build process, the app isn't renameable or relocatable. So to support side-by-side installs of different versions, they need to be named different up front.
I think the DMG file name, the DMG volume name, and the app name are actually all independent, so we could add suffixes or change names for the DMG at will here. My motivation for not adding an "-arm64" suffix to the "main" DMG file is just to make it super easy for non-technical users to decide which file to download from the links in the release page. My assumption is that now in 2024, most non-technical users with Macs will be running Apple Silicon, so if you're a user who doesn't know what "Intel vs. AS vs. ARM etc." means and you just want it to be Simple, there's a default non-suffixed download link and if you click that you'll probably get the right thing. |
|
So actually, let's back up a bit here: maybe there's a way I could publish useful builds for you without worrying so much about DMG naming and stuff? The main point of Octave.app and its DMG releases is to provide an easy installation path for manual interactive users to drag-and-drop something and get a running app. For sophisticated or automated consumers of the builds, maybe there's a better way of publishing it. Wanna tell me about your packaging and distribution workflow, or just point me at a URL to some doco? |
Thank you! This is precisely why this project is so useful to me. Thanks again for this valuable work. |
We have normally removed older versions and replaced with the new version of the .app, and can continue to do this regardless of the name if we are the exception to the rule in the wider community. The DMG file naming standard is something we can work with using regular expressions as part of the Autopkg download activities using URLTextSearcher processor, passing in an argument for the architecture or leave it blank if you want the Apple Silicon to stand out as the default to users, just not what we usually see for other apps that aren't developing a universal app. |
|
Well, rats. I tried the codesign-the-DMG-itself approach, and that didn't do anything to fix the quarantine issue. I decided to give up on that for now, and just go with the "explain the workaround to the user in a big README file" approach. When I found time to do a release candidate build for 8.4.0 that way, my Qt 5 builds started failing, blocking any Octave.app 8.x builds. And gcc builds are failing too, blocking Octave.app 9.x builds. Looks to me like these Qt and gcc build failures are due to a change outside Octave.app, like incompatibility with a new Xcode version or a core formula change or something. My initial approach here is to wait a few days and see if it gets sorted out on the Homebrew side or some other external place. GCC and Qt are big-name enough packages that probably someone will notice this and fix it. Or maybe not, since Homebrew is focused primarily on distributing binary bottle packages and not building everything on a regular basis. See: |
|
I built an 8.4.0 RC1 and published it. Posted a note on the Discourse. Non-xfail test suite failures, on AS (eilonwy): And on Intel (angharad): I don't see anything new in there. Looks like this build might be good. |
|
The real (non-beta) Octave.app 8.4.0 release is live! Updated the https://octave-app.org/ website to make that the current release. Posted announcements in our news locations. Closing this ticket as done, finally! @AppsPackG, if you're interested in pursuing the DMG name change thing, please open a separate issue for that. |
Here's the main ticket to track all the work needed to get Octave.app building again on newer macOS versions from 2020 onward, and to get Octave 8.x (and hopefully 7.x) building and packaged.
This is going to be a high-volume ticket with a bunch of comments and changes, so I made it separate from the existing tickets asking for new builds, so users don't get spammed with notifications about internal development stuff.
The outcome of this ticket should be a new Octave.app 8.x release that runs on (hopefully) macOS 12 and newer.
Related tickets
Blockers:
xattr -cthe DMG" workaround.brew install <octapp>returns exit status 1 (failure) #268make test, breaking build. #250Non-blocking Maybes:
Related, for other releases:
Work branches
I'm doing work on branches named
new-2023-buildsin each of the octave-app, octave-app-bundler, homebrew-octave-app, and create-dmg repos, and more. These will be pretty active branches, with lots of commits and also rebases, so watch out for changes; you'll probably need to get fresh checkouts frequently if you're using them.Approach
Migrating from Homebrew to MacPorts for the Octave.app build would be a large project, and I'm in a hurry to get this out, since users are asking for it and it has been delayed enough already. So I'll stick with Homebrew, give up on supporting macOS versions prior to macOS 11 (or whatever Homebrew currently supports back to), and just get it under that. (Plus, I finally upgraded my own home Mac from macOS 10.14 to 14.)
Some stuff may break in this migration, and I'll prioritize getting a mostly-working build out first, and fix things up in update releases.
Things needed
Needed:
Wanted:
Releases on this track
xattr -cde-quarantining during install to avoid "app is damaged" error.TODO details
The text was updated successfully, but these errors were encountered: