Bug #10146


LinuxLite OS-32bit. CHIRP updated to 20221128 won't launch

Added by David Wieda over 1 year ago. Updated over 1 year ago.

Target version:
Start date:
Due date:
% Done:


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


When updating my CHIRP installation from the downloaded/extracted 20221128-daily.tar.gz via the "sudo python launch" my CHIRP no longer runs via "chirpw".
Found that running it from the CLI provides some feedback on a configuration issue for duplicate driver ID surrounding the BF-T1.

The issue pops up at line 61 in "/user/local/lib/python2.7/dist-packages/chirp/"

I opened the file, scrolled down to line 61 and found an option at line 60/61 of:
raise Exception("Duplicate radio driver id '%s'" % ident)

Since the line group at 58/59 is an "if ALLOW DUPS:" with it's respective "Log a warning" I assumed that I didn't need an exception raised in 61 so I deleted lines 60 and 61 (as noted above).

Saved the file and CHIRP runs perfectly.

I'm NOT a scripting guy, not really even a linux guy.
This installation is a standing VM that I use for maintaining a live linux source (captured via SystemBack) that has all the to the latest software updates, including daily CHIRP loads on a semi-monthly basis. From this "source" VM I'm able to capture a Live Linux ISO image that can be loaded and run from a USB or even DVD. In particular this allows me to run CHIRP from a PC that would normally need a painful amount of drivers and updates for Windows for programming my HT. With Linux and CHIRP, it's MUCH faster and easier. Boot to USB, program HT, reboot back to Windows and move on.
This idea is NOT new, one of the other maintainers referenced in the CHIRP downloads did this already which is where I got the idea - although the other guy's solution was more elegant than mine, it's not been updated in quite some time so I started building my own to make Ham life and my Ham club members' programming lives easier. :- ) I'm happy to post my version if anyone is interested.

-David (KE5BRO)


CHIRP(2022Nov28)_edited.jpg (219 KB) CHIRP(2022Nov28)_edited.jpg Screenshot of feedback from failed CHIRP start. David Wieda, 11/29/2022 08:14 PM
Actions #1

Updated by Dan Smith over 1 year ago

  • Status changed from New to Resolved

This is happening to you because we had to rename a couple of radios that had invalid python-module-spec filenames. If you look in your installed directory, you should see duplicate files with "-" and "_" as the only difference. These are the ones that chirp is complaining about on startup. Delete the ones with the "-" (or just delete the whole installation and re-install) and it should be happy again.

Let me know that this fixed it and I'll close this out.

Actions #2

Updated by Dan Smith over 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF