Running the Artifacts that GitHub creates on a Mac is really painful. That's why for master I create DMGs on my system. If you can't get this to work, I can create a one-off binary for you
/D > On Feb 18, 2020, at 1:10 PM, Martin de Weger <[email protected]> wrote: > > I have downloaded Subsurface-4.9.3-976-gc6f73ae14456.dmg from > https://github.com/Subsurface-divelog/subsurface/releases/tag/ci-release > <https://github.com/Subsurface-divelog/subsurface/releases/tag/ci-release>. > > I did download the app from the GitHub location (I’m not familiair with > GitHub, so I need the explanation / Walkthrough you provided) and tested it > again. > > The signing issue is acting up: > > The default interactive shell is now zsh. > To update your account to use zsh, please run `chsh -s /bin/zsh`. > For more details, please visit https://support.apple.com/kb/HT208050 > <https://support.apple.com/kb/HT208050>. > MacBook-Pro:~ martinw$ /Users/martinw/Software/Contents/MacOS/Subsurface ; > exit;dyld: Library not loaded: @loader_path/../Frameworks/libgit2.28.dylib > Referenced from: /Users/martinw/Software/Contents/MacOS/Subsurface > Reason: no suitable image found. Did find: > /Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: > code signature in > (/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib) not > valid for use in process using Library Validation: library load disallowed by > system policy > /Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: > code signature in > (/Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib) not > valid for use in process using Library Validation: library load disallowed by > system policy > /Users/martinw/Software/Contents/MacOS/../Frameworks/libgit2.28.dylib: > stat() failed with errno=1 > Abort trap: 6 > logout > Saving session... > ...copying shared history... > ...saving history...truncating history files... > ...completed. > Deleting expired sessions...4 completed. > > [Proces voltooid] > > ibhidapi.0.dylib and QtWebKitWidgets.framework cannot be openend. > > > > > Kind regards, > > Martin De Weger > >> Op 18 feb. 2020, om 21:36 heeft Linus Torvalds >> <[email protected] <mailto:[email protected]>> het >> volgende geschreven: >> >> On Tue, Feb 18, 2020 at 12:20 PM Martin de Weger <[email protected] >> <mailto:[email protected]>> wrote: >>> >>> I’ve downloaded the new version and retried to download the dives. The >>> logfile is attached. >> >> Damn. No change. It still tries the other service. >> >> I wonder what went wrong. I see that >> >> Found service "{6e400001-b5a3-f393-e0a9-e50e24dcca9e}" "Unknown Service" >> >> that we _should_ have preferred, but then I see >> >> Using service "{6e400001-b5a3-f393-e0a9-e50e24dc10b8}" as preferred service >> >> (notice the small difference at the end - they look the same if you >> check quickly, but they aren't. >> >> My patch is _so_ simple that I would have expected it to trivially >> pick the right one. >> >> I wonder if you re-downloaded the old App. How did you download it? >> Because it was only done as a pull request, the normal CI pages won't >> get it. >> >> We don't seem to put the git SHA1 commit ID in our normal logs, so I >> can't verify. But the _right_ App image should be reachable from: >> >> https://github.com/Subsurface-divelog/subsurface/pull/2628 >> <https://github.com/Subsurface-divelog/subsurface/pull/2628> >> >> and then you have to Click "Details" on the Mac build: >> >> >> https://github.com/Subsurface-divelog/subsurface/pull/2628/checks?check_run_id=451424356 >> >> <https://github.com/Subsurface-divelog/subsurface/pull/2628/checks?check_run_id=451424356> >> >> and then you have to download it by clicking that "Artifacts" thing in >> the upper right hand corner of the build frame, which should get you a >> download thing that looks something like >> >> Download artifacts >> Subsurface.app 279 MB >> >> and now that "Subsurface.app" is the one you want. >> >> If you got it from any other page, it won't contain my little fixlet >> for the Cressi Cartesio. >> >> And we definitely should add our version string to the log outputs so >> that we can see that it matches the right version. Dirk? >> >> In the meantime, you can check that manually by clicking "Help" and >> then "About Subsurface", and you should see the version string. >> >> For that test-build, the version string *should* be >> >> Subsurface 4.9.3-959-gaa80ecc77ee9 >> >> and if it isn't, you're not testing with my Cressi hack in place. >> >> Linus >> _______________________________________________ >> subsurface mailing list >> [email protected] <mailto:[email protected]> >> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
