Project

General

Profile

Actions

Bug #4479

closed

chirp-daily-20170126 is not launched in OS X Sierra

Added by Erhan Aslanturk almost 8 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
02/02/2017
Due date:
% Done:

100%

Estimated time:
Chirp Version:
daily
Model affected:
(All models)
Platform:
MacOS
Debug Log:
I read the instructions above:

Description

I was running chirp-daily-20161220 without problem in OSX Sierra but after that new releases don't open when click on app icon.

Application size was 5.7MB, but newer ones 3MB. There seems something missing in new releases.


Files

Ekran Resmi 2017-02-02 21.50.53.jpg (32.3 KB) Ekran Resmi 2017-02-02 21.50.53.jpg Erhan Aslanturk, 02/02/2017 10:51 AM

Related issues 2 (0 open2 closed)

Has duplicate Bug #4485: Not working Mac OS X 10.12.3Rejected02/02/2017

Actions
Has duplicate Bug #4503: MacOS crash on launchRejected02/07/2017

Actions
Actions #1

Updated by Michel D. almost 8 years ago

Erhan Aslanturk wrote:

I was running chirp-daily-20161220 without problem in OSX Sierra but after that new releases don't open when click on app icon.

Application size was 5.7MB, but newer ones 3MB. There seems something missing in new releases.

I have the same problem with Sierra OS X 10.12.3

Actions #2

Updated by Tom Hayward almost 8 years ago

I was able to reproduce this, but only once. The first time, I got this error:

open chirp-daily-20170126.app
LSOpenURLsWithRole() failed with error -10810 for the file /Users/tom/Downloads/chirp-daily-20170126.app.

Then I ran:

cd chirp-daily-20170126.app/Contents/MacOS/
./chirp

And it started right up.

Now when I use @open@ or double-click the app, it starts normally.

My hunch is that this has something to do with macOS security protections. Since it works fine once you get past this step, it's apparently not missing anything.

Actions #3

Updated by Michel D. almost 8 years ago

Tom Hayward wrote:

I was able to reproduce this, but only once. The first time, I got this error:

[...]

Then I ran:

[...]

And it started right up.

Now when I use @open@ or double-click the app, it starts normally.

HI,

Same here, now it runs.

Actions #4

Updated by Erhan Aslanturk almost 8 years ago

Yes, following works fine but its a little bit proficient action to have it running. Average Mac users may not do that.

cd chirp-daily-20170126.app/Contents/MacOS/
./chirp
Actions #5

Updated by jim k almost 8 years ago

I experienced this difficulty also - brand new to CHIRP, Sierra 10.12.2. navigating to the folder as per the above and
@sudo ./chirp@
got me launched.

I'm too new and inexperienced to be editing the project's documentation, but perhaps this approach could be noted on the wiki; reordering http://chirp.danplanet.com/projects/chirp/wiki/MacOS_Tips so the current os x version is at the top and better called out as 'hey we have to do weird stuff to appease apple security folk' would be better. I almost gave up after attempting several old install packages, and stumbled on #4485 then found this thread/approach.

Looking forward to coming up to speed with CHIRP.

Actions #6

Updated by Tim Smith almost 8 years ago

  • Target version deleted (0.4.1)
  • Chirp Version changed from 0.4.0 to daily

I think the startup script is causing a sandbox violation that's keeping the app from opening when it tries to symlink the Python framework into the app bundle (so that @argv[0]@ is pretty). Running it from the command line solves the problem because it runs outside the application sandbox. Once the symlink is created, subsequent runs within the app sandbox work fine.

Removing this code from Contents/MacOS/chirp solves the problem:

if [ -x $PYTHON ]; then
    ln -s $PYTHON "${LOCATION}/../CHIRP"
    PYTHON=${LOCATION}/../CHIRP
    export PYTHONPATH="/opt/kk7ds//Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/"
else
    PYTHON=/opt/kk7ds/bin/python2.7
fi

(but makes @argv[0]@ ugly, so the About menu etc have "Python" instead of "CHIRP".)

Actions #7

Updated by Tim Smith almost 8 years ago

It looks like https://stackoverflow.com/questions/14122330/programatically-setting-the-mac-menubar-title offers a solution using ctypes and undocumented APIs...

Actions #8

Updated by Richard Perlman almost 8 years ago

As reported in Bug #4503, The core issue seems to relate to the directory chirp is located in when it is first run. If run from a location other than "Applications" it fails with an error 126. After being moved into "Applications" it starts normally and can then be re-copied elsewhere.

Actions #9

Updated by Tim Smith almost 8 years ago

After a little testing it looks like if it's been moved to /Applications, then the app bundle will always run the first time and can have any name at all. If the app sandbox has different rules for /Applications than e.g. ~/Downloads, that would be consistent with the behavior you're observing; I don't see anything Chirp-specific that asserts that it's being opened from a particular location.

Aha: it looks like we're observing a behavior called "App Translocation" or "Gatekeeper Path Randomization" that applies to quarantined apps run from ~/Downloads. I was a little wrong insofar as it's not a "sandbox" but it does run apps from a temporary read-only volume, which explains why the initialization code that attempts to write into the app bundle causes the app to crash.

This is described at https://weblog.rogueamoeba.com/2016/06/29/sierra-and-gatekeeper-path-randomization/, http://mjtsai.com/blog/2016/06/16/gatekeeper-path-randomization/... and almost not at all on developer.apple.com.

Actions #10

Updated by Tim Smith almost 8 years ago

Chirp can check whether it's being run from a translocated location. Chirp should only attempt the pretty-name hack if it is not translocated.

  • @Ernesto Garcia translocate-status-check some_path@ will print either "TRANSLOCATED" or "NOT TRANSLOCATED" if @translocate-status-check@ is supported.
  • Given an unknown command (as on older versions of OS X, presumably), @Ernesto Garcia@ prints @Ernesto Garcia: unknown command "asdf"@.

This patch tries to add that check:

diff --git a/Contents/MacOS/chirp b/Contents/MacOS/chirp
index 5386485..dab4777 100755
--- a/Contents/MacOS/chirp
+++ b/Contents/MacOS/chirp
@@ -4,7 +4,11 @@ LOCATION=$(dirname "${BASH_SOURCE}")
 
 PYTHON=/opt/kk7ds//Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
 
-if [ -x $PYTHON ]; then
+not_translocated () {
+    security translocate-status-check "$LOCATION" 2>&1 | grep -q -e NOT -e unknown -e "not found"
+}
+
+if [ -x $PYTHON ] && not_translocated; then
     ln -s $PYTHON "${LOCATION}/../CHIRP"
     PYTHON=${LOCATION}/../CHIRP
     export PYTHONPATH="/opt/kk7ds//Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/"
Actions #11

Updated by Tim Smith almost 8 years ago

  • Status changed from New to In Progress
  • Assignee set to Tim Smith
  • % Done changed from 0 to 100

The next daily (20170209 or later) incorporates a fix.

Actions #12

Updated by Tim Smith over 7 years ago

  • Status changed from In Progress to Closed

Closing as fixed.

Actions #13

Updated by RJ Anderson over 7 years ago

Hi, Just got chrip 20170518 build, OSX 10.12.5. App will not open at all (even from Applications). Tried all above. Still won't open (double click launches something which exits immediately without any UI or error). Thx.

Actions #14

Updated by RJ Anderson over 7 years ago

RJ Anderson wrote:

Hi, Just got chirp 20170518 build, OSX 10.12.5. App will not open at all (even from Applications). Tried all above. Still won't open (double click launches something which exits immediately without any UI or error). Thx.

Actions #15

Updated by RJ Anderson over 7 years ago

I get this if this is helpful:
Last login: Fri May 19 14:54:21 on ttys000
Robs-Imac-Retina-2:~ robertanderson$ /Applications/Chirp.app/Contents/MacOS/chirp ; exit;
/Applications/Chirp.app/Contents/MacOS/chirp: line 19: /opt/kk7ds/bin/python2.7: No such file or directory
/Applications/Chirp.app/Contents/MacOS/chirp: line 19: exec: /opt/kk7ds/bin/python2.7: cannot execute: No such file or directory
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Process completed]

but no application window ever shows. It looks like it's not finding "Python 2.7", although I downloaded and installed that explicitly, but that didn't help. thx

Actions #16

Updated by RJ Anderson over 7 years ago

Resolved, apparently, there are multiple Python 2.7 downloads out there, the only one that this seems to work with is: http://www.d-rats.com/download/OSX_Runtime/KK7DS_Python_Runtime_R10.pkg
Installing that fixed the issue.

Actions #17

Updated by Jim Unroe over 7 years ago

RJ Anderson wrote:

Resolved, apparently, there are multiple Python 2.7 downloads out there, the only one that this seems to work with is: http://www.d-rats.com/download/OSX_Runtime/KK7DS_Python_Runtime_R10.pkg
Installing that fixed the issue.

I'm glad you got it resolved. It does tell you to install that package in the MacOS Users section of the CHIRP download page (quoted below).

Jim

Actions

Also available in: Atom PDF