CHIRP

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

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.

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.

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

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.

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

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.

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.

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/"

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.

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.

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

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.

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).

• New Mac OS X must install the runtime once before running CHIRP. After it is installed, the runtime does not need to be downloaded or installed each time. Download the "KK7DS Python runtime":http://www.d-rats.com/download/OSX_Runtime/KK7DS_Python_Runtime_R10.pkg for Mac OSX.

Jim