CHIRP

On my Mac, I get a warning that the Python Runtime will no longer be compatible with Mac OS 10.15. I have not yet upgraded to Mac OS 10.15. I'm still running 10.14.

Is Chirp compatible with Mac OS 10.15 (64-bit)?
Will the Python Runtime necessary to run Chirp be compatible with Mac OS 10.15 (64-bit)?

I don't want to upgrade until I'm sure I can still use Chirp.

Thank you for any information you can provide.

Robert PAVIA wrote:

My CHIRP is no longer compatible with my MAC since OS version 10.15

Mon CHIRP n'est plus compatible avec mon MAC depuis la version OS 10.15

The python in the runtime is 32-bit and won't work on Catalina. The new "unified" build uses the system python executable which is 64-bit and ideally will work under Catalina for now. I haven't upgraded myself, so I haven't been able to confirm, which is why I'm asking the OP to test.

In general, upgrading to a new version of the OS shortly after it is released is a terrible idea anyway (despite the fact that Apple has trained its users to the contrary), so you're really taking a risk if you upgrade now. If you do, let me know if the unified build works :)

Got it. So the unified Chirp contains the python runtime in it and should be 64-bit/Catalina compatible? That's the "chirp-unified-daily-20190925.app" that's on the download page, correct? It says that it's currently experimental. In the future, will the unified version be the most reliable one to use with Catalina, or are you hoping that they separate python runtime will someday be upgraded to be 64-bit compatible?

I'm in no hurry to upgrade to Catalina. I have a number of other professional audio programs that need to be verified with Catalina first before I can upgrade, but I just wanted to see what the upgrade path was for Chirp.

Thanks so much for your help.

It's experimental because it has only existed for a couple of weeks and I haven't gotten a lot (or any really) reports that it works well. Yes, it contains the full python stack inside (minus the actual interpreter) and is hopefully Catalina-compatible. But, we need people to confirm that.

CHIRP-wise, it has the same exact content inside it as the regular build. If it works, works in Catalina, and the non-unified version does not work in Catalina (which we know is true), then I'll only generate the unified build in the future.

Awesome. Good to know. If I have the chance to upgrade one of my computers to Catalina to test your unified build, I'll let you know. Thanks again.

Reporting from Catalina with chirp-unified-daily-20190925.app:
The application runs without kkd7 but after trying to open my *.img files (from File->Recent) nothing happens. This seems to be caused by the increased security in Catalina; CHIRP should include the user's documents directory in its sandbox as part of "Signing and Capabilities".
You can see this behavior by trying to open your *.img files using File->Open and navigating to your "Documents" folder; you should get an "Operation Not Permitted" error.

Workaround: I copied my *.img files to: "/Applications/CHIRP.app/Contents/Resources/chirp/stock_configs" and used the File->Open menu to access them.

This +workaround+ presents the clear danger of loosing any changes made to the *.img file every time we update the application.
I left a copy in my usual folder and plan to maintain it updated with any changes made in the application until a better solution is found.

I confirm what Sergio Leeb said. I have a Mac with Catalina; Brew-installed chirp did not work. unified-daily-20190925 worked in my downloads directory, but would not load .img files, even if they were moved into the chirp.app tree. When I moved the chirp.app to the Applications directory, it worked as he noted and I was able to load my local repeaters to my HT. I agree with him that it would be a Good Thing to have chirp be able to access the user's Documents directory.

I don't know that this is something I can control, but I will look into it. We don't generate a signed app (doing so costs money and is not feasible to integrate into the automated build process) and I believe that's where I'd get to state what the app should have access to.

In the meantime, if you could try another workaround:

System Prefs -> Security & Privacy -> Privacy -> Full Disk Access

Click + and try adding /usr/bin/python to the exclusion list. If that does not work, try adding the CHIRP app itself. You may need to hit Shift+Command+. (period) while in the file browser in order to find /usr.

Let me know if and what works so we can at least document it (and maybe pop up a warning in the app itself) and I'll look to see what else can be done.

I tried adding /usr/bin/python to the exclusion list. After doing Shift+Command+. I navigated to /usr/bin and found python, but it was greyed out and I could not select it. So was python2.7. But python3 was not greyed out, so I selected it. When I then ran CHIRP I was not able to search in my Documents folder. I then tried to add the CHIRP.app to the list, same result: "Operation not permitted". Interestingly, it seems that my ~/Documents directory is blocked, bot others, such as my Dropbox directory, are not. So I tried creating a symlink in my ~ : ln -s ~/Documents/Radio/Chirp ~/Chirp And then tried accessing the symlink. This Jedi Mind Trick didn't work, either. But when I created a ~/Chirp2 directory and copied the configuration files from ~/Chirp to ~/Chirp2, that was accessible by Chirp. Then just for fun, I created a symlink in ~/Documents/Chirp2 that pointed to the ~/Chirp2 directory (to see if the restriction on access to ~/Documents would somehow stick to the symlink). That did not change the ability of Chirp to access the directory.

So it seems like my workaround is going to be to have a chirp configurations directory at my ~ level, then link to that from within my ~/Documents/Radio/Chirp directory. That way it will still appear where I have gotten used to it being, but it will also be accessible to chirp and won't get lost when new versions of chirp are loaded. One small downside is that I have to remember to look in a different place.

I dunno why you can't select one of the python2s, but python3 will have no effect on chirp. Have you tried adding chirp itself?

Either way, the workarounds will confuse the heck out of regular users of course. If this is how it's going to be with Catalina and beyond, it may just be time to throw in the towel and drop official support for MacOS. Feel free to send your grievances to Apple :/

As a new HAM who is trying to set up emergency communications in my local area, I would be very sad if you dropped Mac support. Is there any way that I can help? Does granting full disk access to the unified version of Chirp not allow it to access the user's Documents folder? I too keep my Chirp files in my dropbox so I can access them on multiple computers if I have to program radios in different locations on different computers. I'm still waiting to upgrade to Catalina until my professional audio program, Avid's ProTools, becomes compatible with Catalina.

Crispin, I've asked for people to try that but I have not heard that anyone has. So yes, please try. However, I have heard that other apps that use interpreted languages have to have their interpreter (i.e. /usr/bin/python in this case) added to the list. If you could give both a try (as it should be possible to add python, python2, or python2.7) to the list.

Hey Dan. You are the best. CHIRP is so great, that I want to help. I am a long time IT Support pro, and Mac user. I was a Catalina Beta user, and upgraded to the production version on the first day. Was sad it Didn't work, but was patiently waiting for you to figure it all out. You have made great strides. Thanks.

I am running the 10.15 with the Update (they did not number it). Had 20190829 running previously. Read this thread, installed the unified daily from 20191019. Then I went into System Prefs->Security & Privacy->Privacy->Full Disk Access then I added both Python 3 and Chirp. Your instructions above were helpful. If they are required for everyone, just publish them. I didn't mind.

ANYWAY, Once I completed the steps, I ran the app. The first time I run it, I had to allow it on the General tab of this same System Preference. Then the application started. To my surprise, my IMG's were listed in RECENT as well as OPEN.

However, like a fool, I did not bring my USB-C adapter home, so I can't actually test connecting to the radio. I will post again as soon as I get connected. But, I am feeling optimistic already.

Thanks Dan.

I too am incredibly grateful to Dan for all his work on CHIRP. While I'm a long time Mac user (since 1985) and was a computer science minor in college, I cannot call myself an IT Support Pro person and I've never beta tested software. I'm grateful to you, Bob, for testing all of this. I look forward to hearing if you can make everything work once you get the right cables together.

I know how to allow an application like CHIRP to get full disk access, but can I ask, where is Python 3 so I can follow your steps? Is Python 3 in the Applications folder, some other folder, or inside the CHIRP unified app?

I can't really upgrade to 10.15 until Avid's Pro Tools is compatible since I work in the professional audio world, but I want to make sure I can get CHIRP working under 10.15 when I do.

Thanks again to all of you.

Guys, python3 has nothing to do with CHIRP. Adding it to the list will not have any effect. CHIRP runs on python2 (python2.7).

So Bob, are you saying that adding chirp itself to the full disk access box allows you to access your home, documents, etc directory?

As I noted in my update above, I did add CHIRP.app to the list and it did not change the behavior for me. I also noted a work-around that works for me without having CHIRP.app in the list.

I thought the issue might be related to symlinks in the path to the executable, but when I unwrapped all the symlinks I got

$ ls -l /usr/local/Cellar/python@2/2.7.16_1/Frameworks/Python.framework/Versions/2.7/bin/python2.7
-rwxr-xr-x  1 johnderoo  staff  13316 Oct  5 14:44 /usr/local/Cellar/python@2/2.7.16_1/Frameworks/Python.framework/Versions/2.7/bin/python2.7

and when I tried to add that to the list, python2.7 and everything else in that directory, were greyed out.

Yes, Dan.

Also, I was able to download from my radio this evening. Looks like I am back in business. Thanks.

So I've tried the unified builds and they're not opening on Catalina.

Is there any definitive fix yet? Update to a 64-bit version of Python (waiting on an answer before doing this)? Add Chirp to Full Disk Access in System Prefs (did it, same thing - not opening)?

Seeing how python 2.7 is 32-bit I would think that is the culprit and that Catalina no longer allows 32-apps, but I'm no developer.

But following the directions above, nothing changed. I had a python3 file (no file extension - exec file?) that I was able to select and add to Full Disk Access, no change. I found a Python.app that has Apple's white circle with a slash through it (32-bit app).

Thanks.

I have found a workaround for not being able to access the Documents folder. Create a folder inside your home folder (the same place the Documents folder sits) and move your Chirp files into there. This doesn't actually fix the problem and you can't access any external drives either, but this will give the developers of whatever app is responsible time to correct the root cause which is the fact that Chirp cannot ask permission to access these folders.

So I downloaded the unified CHIRP version to my Mac that is running Catalina 10.15, and it opens just fine. I have had the same problems as everyone else in that you cannot access any directories. However, I connected my Baufeng radio and was able to retrieve the contents of its memory, change it, then upload it back to the radio without any problems. So if you have a radio that has the memory items that you want, you can easily use CHIRP to send it to other radios. Not a perfect solution, but at least I am able to do something. You can also start from scratch and create a new table.

I also wanted to mention that you can copy your CHIRP files into the "HOME" directory and you can access them just fine. That was mentioned by John McFerren and it works. At this point CHIRP is fully functional on Catalina 10.15.

What did everyone do to get Chirp to actually open? I'm not talking about documents or anything else. Just the APP itself? Unified build from 10/29 still starts to open in my dock, bounces a few times and then disappears. And I have told my Mac to open the unsigned app (System Prefs - Security & Privacy).

Unified build works fine for me now on Catalina -- thanks to tip about acessing a directory outside Documents.

I created a Chirp folder in my own users folder (same level as Documents, etc.).
started Chirp from Applications folder via ctrl-Open
ignored errors about permissions in Documents; navigated to Chirp/
opened a sample .img file I had copied earlier to Chirp/
save as worked too.

although it might be nice to be able to specify a regular folder like Downloads, it doesn't seem necessary, given this quite adequate workaround.

thanks
Steve
p.s. perfect timing since our CERT group (Ashland, OR) will be doing major updates to our channel lists & comms plan in next month or two.

Dan Smith wrote:

It's experimental because it has only existed for a couple of weeks and I haven't gotten a lot (or any really) reports that it works well. Yes, it contains the full python stack inside (minus the actual interpreter) and is hopefully Catalina-compatible. But, we need people to confirm that.

CHIRP-wise, it has the same exact content inside it as the regular build. If it works, works in Catalina, and the non-unified version does not work in Catalina (which we know is true), then I'll only generate the unified build in the future.

Creator of the unified build here...

Actually, it even has it's own python interpreter inside the bundle, in the file CHIRP.app/Contents/CHIRP. Outside python settings and packages can cause it to use external files however. The python interpreter is named "CHIRP" inside the bundle because that is an easy way to trick the system into displaying the program name as "CHIRP" instead of "python". It does rely on /System/Library/Frameworks/Python.framework though at the current time.

This is the current loader script, note that it does search /Library/Python/2.7/site-packages first, so external python packages you have installed could possibly override the local ones.

#!/usr/bin/env bash

LOCATION=$(dirname "${BASH_SOURCE}")

PYTHON="${LOCATION}/../CHIRP"
export PYTHONPATH="/Library/Python/2.7/site-packages:$LOCATION/../Resources/site-packages:."
export DYLD_FALLBACK_LIBRARY_PATH="$LOCATION/../Resources/lib"

exec "$PYTHON" "${LOCATION}/../Resources/chirp/chirpw"

Jeff 2A wrote:

What did everyone do to get Chirp to actually open? I'm not talking about documents or anything else. Just the APP itself? Unified build from 10/29 still starts to open in my dock, bounces a few times and then disappears. And I have told my Mac to open the unsigned app (System Prefs - Security & Privacy).

Try going to a command prompt and typing: /Applications/CHIRP.app/Contents/MacOS/chirp to run the launch from the command line. Post the output here. I'm guessing you might have installed python packages on you Mac that may be conflicting.

Jeff 2A wrote:

What did everyone do to get Chirp to actually open? I'm not talking about documents or anything else. Just the APP itself? Unified build from 10/29 still starts to open in my dock, bounces a few times and then disappears. And I have told my Mac to open the unsigned app (System Prefs - Security & Privacy).

Try going to a command prompt and typing: /Applications/CHIRP.app/Contents/MacOS/chirp to run the launcher from the command line. Post the output here. I'm guessing you might have installed python packages on you Mac that may be conflicting.

I also have this problem since upgrading to Catalina.
Downloaded the latest Mac version chirp-daily-20191206.app
It will not run.

Ben, please follow the directions given above and post the resulting output so I can assist you further.

Here are the instructions again.

Go to a command prompt and type:
/Applications/CHIRP.app/Contents/MacOS/chirp
to run the launcher from the command line. Post the output here. That is assuming you have copied/installed CHIRP into your Applications folder.

Fellow Mac user with the bouncy icon and then nada. Here's my output from running the app in the terminal:

@
Traceback (most recent call last):
File "/Applications/CHIRP.app/Contents/MacOS/../Resources/chirp/chirpw", line 131, in
from chirp.ui import mainapp
File "/Applications/CHIRP.app/Contents/Resources/chirp/chirp/ui/mainapp.py", line 26, in
import gtk
File "/Applications/CHIRP.app/Contents/Resources/site-packages/gtk/init.py", line 40, in
from gtk import gtk
File "/Applications/CHIRP.app/Contents/Resources/site-packages/cairo/init_.py", line 1, in
from ._cairo import * # noqa: F401,F403
ImportError: dlopen(/Applications/CHIRP.app/Contents/Resources/site-packages/cairo/_cairo.so, 2): Library not loaded: /usr/local/opt/cairo/lib/libcairo.2.dylib
Referenced from: /Applications/CHIRP.app/Contents/Resources/site-packages/cairo/_cairo.so
Reason: Incompatible library version: _cairo.so requires version 11603.0.0 or later, but libcairo.2.dylib provides version 11403.0.0
@

A quick google of the incompatible versions gives some good reading, however I don't know why my computer would have a different library version than what's expected. Any help would be greatly appreciated.

Thanks!

Barry Nelson wrote:

Ben, please follow the directions given above and post the resulting output so I can assist you further.

Here are the instructions again.

Go to a command prompt and type:
/Applications/CHIRP.app/Contents/MacOS/chirp
to run the launcher from the command line. Post the output here. That is assuming you have copied/installed CHIRP into your Applications folder.

You have apparently installed an incompatible library in /usr/local/opt/cairo/lib/libcairo.2.dylib. Remove it and CHIRP should load. This file does not come with your Mac, it is something you added, perhaps using brew or Mac ports. Perhaps some other software you installed placed it there.

Alternatively, you could try editing "/Applications/CHIRP.app/Contents/MacOS/chirp" and adding export DYLD_VERSIONED_LIBRARY_PATH="$LOCATION/../Resources/lib" as shown below..
If you try this, please let me know if this works. New "/Applications/CHIRP.app/Contents/MacOS/chirp" file contents would look like this:

#!/usr/bin/env bash

LOCATION=$(dirname "${BASH_SOURCE}")

PYTHON="${LOCATION}/../CHIRP"
export PYTHONPATH="/Library/Python/2.7/site-packages:$LOCATION/../Resources/site-packages:."
export DYLD_FALLBACK_LIBRARY_PATH="$LOCATION/../Resources/lib"
export DYLD_VERSIONED_LIBRARY_PATH="$LOCATION/../Resources/lib"

exec "$PYTHON" "${LOCATION}/../Resources/chirp/chirpw"

Thank you, Barry! It's running as intended :)

Thank you again!

Barry Nelson wrote:

You have apparently installed an incompatible library in /usr/local/opt/cairo/lib/libcairo.2.dylib. Remove it and CHIRP should load. This file does not come with your Mac, it is something you added, perhaps using brew or Mac ports. Perhaps some other software you installed placed it there.

Alternatively, you could try editing "/Applications/CHIRP.app/Contents/MacOS/chirp" and adding export DYLD_VERSIONED_LIBRARY_PATH="$LOCATION/../Resources/lib" as shown below..
If you try this, please let me know if this works. New "/Applications/CHIRP.app/Contents/MacOS/chirp" file contents would look like this:

#!/usr/bin/env bash

LOCATION=$(dirname "${BASH_SOURCE}")

PYTHON="${LOCATION}/../CHIRP"
export PYTHONPATH="/Library/Python/2.7/site-packages:$LOCATION/../Resources/site-packages:."
export DYLD_FALLBACK_LIBRARY_PATH="$LOCATION/../Resources/lib"
export DYLD_VERSIONED_LIBRARY_PATH="$LOCATION/../Resources/lib"

exec "$PYTHON" "${LOCATION}/../Resources/chirp/chirpw"

Installed the latest and cannot for the life of me get it to run. When running via the command line here is the output:

Scalene:MacOS rgillis$ pwd
/Applications/CHIRP.app/Contents/MacOS
Scalene:MacOS rgillis$ ./chirp
2019-12-15 19:20:57.626 CHIRP[24698:3152103] *** WARNING: Method userSpaceScaleFactor in class NSView is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead.
WARNING: Icon not found
objc[24698]: Class GdkQuartzView is implemented in both /Applications/CHIRP.app/Contents/Resources/lib/libgdk-quartz-2.0.0.dylib (0x10f9320c8) and /opt/gtk/lib/libgdk-quartz-2.0.0.dylib (0x113c9ca10). One of the two will be used. Which one is undefined.
objc[24698]: Class GdkQuartzWindow is implemented in both /Applications/CHIRP.app/Contents/Resources/lib/libgdk-quartz-2.0.0.dylib (0x10f932118) and /opt/gtk/lib/libgdk-quartz-2.0.0.dylib (0x113c9ca60). One of the two will be used. Which one is undefined.
objc[24698]: Class GtkQuartzStatusIcon is implemented in both /Applications/CHIRP.app/Contents/Resources/lib/libgtk-quartz-2.0.0.dylib (0x10f803ac8) and /opt/gtk/lib/libgtk-quartz-2.0.0.dylib (0x113b62c90). One of the two will be used. Which one is undefined.
objc[24698]: Class GtkClipboardOwner is implemented in both /Applications/CHIRP.app/Contents/Resources/lib/libgtk-quartz-2.0.0.dylib (0x10f803b18) and /opt/gtk/lib/libgtk-quartz-2.0.0.dylib (0x113b62ce0). One of the two will be used. Which one is undefined.
objc[24698]: Class GtkDragSourceOwner is implemented in both /Applications/CHIRP.app/Contents/Resources/lib/libgtk-quartz-2.0.0.dylib (0x10f803b68) and /opt/gtk/lib/libgtk-quartz-2.0.0.dylib (0x113b62d30). One of the two will be used. Which one is undefined.
objc[24698]: Class ResultReceiver is implemented in both /Applications/CHIRP.app/Contents/Resources/lib/libgtk-quartz-2.0.0.dylib (0x10f803be0) and /opt/gtk/lib/libgtk-quartz-2.0.0.dylib (0x113b62d80). One of the two will be used. Which one is undefined.

(process:24698): GLib-GObject-CRITICAL **: gtype.c:2712: You forgot to call g_type_init()

(process:24698): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
/opt/gtk/lib/python2.7/site-packages/gtk_osxapplication/init.py:25: Warning: g_type_get_qdata: assertion 'node != NULL' failed
from gtk_osxapplication import _gtk_osxapplication
Segmentation fault: 11

Any ideas?

I got this:

Traceback (most recent call last):
File "/Applications/CHIRP.app/Contents/MacOS/../Resources/chirp/chirpw", line 131, in
from chirp.ui import mainapp
File "/Applications/CHIRP.app/Contents/Resources/chirp/chirp/ui/mainapp.py", line 26, in
import gtk
File "/Applications/CHIRP.app/Contents/Resources/site-packages/gtk/init.py", line 40, in
from gtk import _gtk
ImportError: dlopen(/Applications/CHIRP.app/Contents/Resources/site-packages/gtk/_gtk.so, 2): Library not loaded: /usr/local/opt/fontconfig/lib/libfontconfig.1.dylib
Referenced from: /Applications/CHIRP.app/Contents/Resources/lib/libpangocairo-1.0.0.dylib
Reason: Incompatible library version: libpangocairo-1.0.0.dylib requires version 14.0.0 or later, but libfontconfig.1.dylib provides version 11.0.0

I followed these instructions:

Alternatively, you could try editing "/Applications/CHIRP.app/Contents/MacOS/chirp" and adding export DYLD_VERSIONED_LIBRARY_PATH="$LOCATION/../Resources/lib" as shown below..
If you try this, please let me know if this works. New "/Applications/CHIRP.app/Contents/MacOS/chirp" file contents would look like this:

#!/usr/bin/env bash

LOCATION=$(dirname "${BASH_SOURCE}")

PYTHON="${LOCATION}/../CHIRP" 
export PYTHONPATH="/Library/Python/2.7/site-packages:$LOCATION/../Resources/site-packages:." 
export DYLD_FALLBACK_LIBRARY_PATH="$LOCATION/../Resources/lib" 
export DYLD_VERSIONED_LIBRARY_PATH="$LOCATION/../Resources/lib"

exec "$PYTHON" "${LOCATION}/../Resources/chirp/chirpw"

BINGO BANGO! IT WORKED! Chirp FINALLY opened!

Thanks Barry!

The error opening your img file is probably due to Mac OS restricting access to unsigned files, but there is an exceeding silly way to disable this restriction. Move CHIP.app to any other folder, run it once, then move it back.

As outlined at http://weblog.rogueamoeba.com/2016/06/29/sierra-and-gatekeeper-path-randomization/, macOS Sierra introduces a new security feature called "Gatekeeper Path Randomization" (or "app translocation", as it's called on the API level). The basic gist is that if you download and run a Gatekeeper app from the Downloads folder, the OS will copy the app into a read-only disk image and run it from there instead. See the link above for more details.

This applies until the user moves the app to any other location (not just the Applications folder), after which the OS will just run the app normally. However, the move is only recognized if performed using the Finder. If you move the app another way, e.g. using "mv" in the Terminal, the app will continue to be translocated when run, even if it's in /Applications.

I am going to recommend that the line
export DYLD_VERSIONED_LIBRARY_PATH="$LOCATION/../Resources/lib"
be added to the standard build to avoid this library conflict issue in the future.

New update of Chirp (chirp-unified-daily-20200103.app.zip doesn't even open after installing in.

And I added the export DYLD_VERSIONED_LIBRARY_PATH="$LOCATION/../Resources/lib" again.

Yes. PLEASE add this to the builds!

Assuming you have moved CHIRP to /Applications please run this command from the command prompt and post the output.

/Applications/CHIRP.app/Contents/MacOS/chirp

Please try the latest +unified+ build. It should have the

export DYLD_VERSIONED_LIBRARY_PATH="$LOCATION/../Resources/lib"

Here's another datapoint on the unified build.

I've been running the Homebrew release, but it stopped working after upgrading to Catalina (currently running 10.15.2).

Today I removed the Homebrew build and installed chirp-unified-daily-20200107.app into my Applications directory. Since the application is unsigned I could not just double click to run it the first time, instead I held control while clicking and selected "open", which allowed me to bypass the security warning. This is another workaround for running unsigned apps.

Based on the discussion in this issue I put my data files under ~/Work instead of under ~/Documents.

With the above setup I was able to download an image from my radio, make updates, save files to disk, and then upload back to the radio.

--

While importing from a CSV I ran into an issue (0 in the DTCS code field is apparently no longer allowed) and needed to see the logs. I started Chirp using the command line and was able to see the logs and diagnose the issue.

/Applications/CHIRP.app/Contents/MacOS/chirp

I think we can close this report. I have helped multiple people get CHIRP running on MacOS 10.15. In every case, where it initially was not working it was caused by other software they had installed interfering with CHIRP.

Further notes for those on MacOS trying to get CHIRP to run:
In most cases CHIRP is compatible with other software however, if it will not run, try removing any other software packages you have installed that use Python, including but not limited to Python runtime packages, especially any 32 bit Python libraries, etc.

The CHIRP "unified" build is 64 bit and runs on MacOS 10.13 or later and you do not need to install any Python runtime package. This version requires at least MacOS 10.13.
The CHIRP legacy build runs on 10.13 and EARLIER and requires the KK7DS Python runtime, this version will NOT run on 10.15.

If anyone has a specific issue, we should open a ticket.

I just checked the latest version on 2020-03-02.
CHIRP Daily-20200227
GTK 2.24.32
PyGTK 2.24.0
Python 2.7.16
If you simply RIGHT CLICK on the application, it provides an OPEN button. (Use a mouse or enable right click in OSX)
Click Open.
All functions that I can see work, such as browsing ANYWHERE on the disk to get image files.
This was without installing anything but the latest version of Chirp.

I'm basically not a macOS user so I am like a fish out of water when trying to use it. The first thing I did was perform a clean install of Catalina on my MacBook Air. After that I downloaded the most recent CHIRP macOS Unified Application. There was no right-click choice available to open it. As expected, left-clicking the file was blocked from opening because of it not being signed. So I used the Security & Privacy app to "Allow" CHIRP to open.

CHIRP cannot access the Desktop, Documents or Download folders (even after granting CHIRP "Full Disk Access").
CHIRP has no problem accessing the Library, Movies, Music, Pictures or Public folders.
As mentioned above, I just created a "CHIRP" folder to store CHIRP Radio Images (*.img) file and CSV files.

Lastly, I installed a 3rd party device driver for my programming cable with a Prolific type USB-to-Serial chip and was successful at downloading from and uploading to one of my CHIRP supported radios.

As far as I can tell, other than not having access to the folders mentioned above, CHIRP opens and runs fine on macOS Catalina for me.

Jim KC9HI

Jim Unroe, there is an earlier comment about Mac OS restricting access to unsigned files, but there is an exceeding silly way to disable this restriction. Move CHIP.app to any other folder, run it once, then move it back.

As outlined at http://weblog.rogueamoeba.com/2016/06/29/sierra-and-gatekeeper-path-randomization/, macOS Sierra introduces a new security feature called "Gatekeeper Path Randomization" (or "app translocation", as it's called on the API level). The basic gist is that if you download and run a Gatekeeper app from the Downloads folder, the OS will copy the app into a read-only disk image and run it from there instead. See the link above for more details.

This applies until the user moves the app to any other location (not just the Applications folder), after which the OS will just run the app normally. However, the move is only recognized if performed using the Finder. If you move the app another way, e.g. using "mv" in the Terminal, the app will continue to be translocated when run, even if it's in /Applications.

Can we close this issue please? CHIRP runs fine on Catalina now. This is is just attracting posts here that should be opened as a separate ticket.