Bug #9742

Chirp with python3 not working on Linux

Added by Jim Lynch 5 months ago. Updated about 1 month ago.

Status:Feedback Start date:02/06/2022
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:-
Target version:-
Chirp Version:daily Platform:Linux
Model affected:(All models)

Description

At least I can't seem to make it work. I downloaded the chirp-daily-20220202, detared it and then tried to run chirpw and got the following error:

Traceback (most recent call last):
File "chirpw", line 20, in <module>
from chirp import chirp_common
File "/home/jwl/chirp-daily-20220202/chirp/chirp_common.py", line 979
except errors.InvalidDataError, e:
^
SyntaxError: invalid syntax

So I found this site: https://chirp.danplanet.com/projects/chirp/wiki/Linux_Python3
And followed the directions since I'm running Mint 20 which is a derivative of Ubuntu.
I ran this command as indicated in the INSTALL file:
sudo python setup.py install --record files.txt
Then I did a chmod +x chirpc and ./chirpc and it gave me a boatload of errors such as:
Failed to import /home/jwl/chirp-daily-20220202/chirp.hg/chirp/drivers/lt725uv: invalid syntax (lt725uv.py, line 1396)
Failed to import /home/jwl/chirp-daily-20220202/chirp.hg/chirp/drivers/gmrsuv1: invalid syntax (baofeng_common.py, line 167)
Failed to import /home/jwl/chirp-daily-20220202/chirp.hg/chirp/drivers/ft50: invalid syntax (ft50.py, line 589)

Then I attempted to run chirpw and got:
Traceback (most recent call last):
File "./chirpw", line 139, in <module>
from chirp.ui import mainapp
File "/home/jwl/chirp-daily-20220202/chirp.hg/chirp/ui/mainapp.py", line 33, in <module>
from chirp.drivers import ic9x, kenwood_live, idrp, vx7, vx5, vx6
File "/home/jwl/chirp-daily-20220202/chirp.hg/chirp/drivers/vx6.py", line 874
except Exception, e:
^
SyntaxError: invalid syntax

In addition to a bunch of the "Failed to import ..." like before.

Can anyone help?
Thanks.

History

Updated by Jim Unroe 5 months ago

  • Status changed from New to Feedback

This is because CHIRP continues to be a Python2 application and has not fully been updated to Python3 yet. Support for Python 2 and some other CHIRP dependencies were dropped from Ubuntu 20.xx (which Mint is based on) which prevents CHIRP from running natively without the user adding Python2 and tracking down and installing a few other dependencies. That is why the flatpak build was created. It contains Python2 and the missing dependencies (except for "future" which can easily be added if your radio requires it -- 5 radio drivers require it).

Jim KC9HI

Updated by David McMackins 4 months ago

This has become a significant issue for Raspberry Pi users. The latest Pi OS is based on Debian Bullseye which also removes these python2 dependencies. The flatpak image would work, except it's specific to x86_64 architecture and won't install on armhf or arm64 systems. A lot of people use Raspberry Pis in the shack, and now they will have to run outdated software to be able to program their radios.

Python 2's end of life was 2 years ago, and the Python developers gave 10 years' notice that it was deprecated. This should be made a higher priority issue. The flatpak build is a band-aid to put off necessary updates to the software. I'd be happy to help myself if that's necessary.

Updated by Tony Fuller 4 months ago

Hi David,

I created the original flatpak build script that builds the x86 packages. Dan has updated it since but you're more than welcome to take a look at the original version at https://gist.github.com/goldstar611/cb0037ee29ae315bb2f0211e69d95799 Everything is built from source so it should work on the raspberry pi. It would be great to hear back if it works.

I'll ping Dan to see if his improved flatpak version is public somewhere.

This is a band-aid, but we do what we can with what we've got :D

Updated by Tony Fuller 4 months ago

Hi David, I have investigated how to build AppImages for 64-bit Intel, 64-bit ARM and 32-bit ARM architectures. I've tested them on my desktop computer and raspberry pi with a Baofeng 888s radio and am soliciting feedback from others. I would love to know if it works for you (best to try on a cheaper model first). There are no runtimes or other requirements. Just mark the binary as executable and run it.

https://github.com/goldstar611/chirp-appimage/releases/tag/02Mar2022

If I get a few more thumbs up I'll propose to Dan if we can move to AppImages.

Thanks,
Tony

Updated by David McMackins 4 months ago

AppImages are superior to flatpaks from a convenience perspective, but ultimately it's still a band-aid. Python is supposed to be architecture-agnostic. We shouldn't have to worry about building fat binaries for different architectures when we could instead put that effort toward building CHIRP upon a platform that isn't abandoned by its developers (i.e. Python 2.x).

It's pretty sorry when your program's dependencies are so out of date they can't even be found in Debian stable, which is notorious for having out-of-date packages. Interestingly, Debian does have a chirp package, but it's based on a very old version of CHIRP. I imagine some maintainer patched it to work with Debian's Python libraries but couldn't be bothered to keep it up.

I should be able to download the CHIRP source and run it in place. The fact that I can't do this in Debian should be seen as an embarrassment. Offering pre-built fat binaries with all the dependencies is not a solution; it's willful ignorance of the problem.

Let me be clear that I am not just hurling insults while being unwilling to put the effort in myself. I am more than willing to give it a go so long as I get advance notice that my work will actually get merged upstream. I don't want to put in the hours (like that Debian maintainer may have) of getting CHIRP up to date only to be told that it isn't appreciated and the project will continue running on abandonware.

Updated by Tony Fuller 4 months ago

Hi David,

We (I think I speak for most of us) are completely aware of the situation. :) But there will be many chirp drivers that won't get ported to python3 for a long time either due to developer resource constraints or physical resource constraints, maybe both. Your feedback on the appimage is helpful to those other hams who are waiting for the python3 version.

Thanks,
Tony

Updated by Calin Brabandt about 1 month ago

If I get a few more thumbs up I'll propose to Dan if we can move to AppImages.

Tony, Dan:

I've been pulling my hair out trying to get Chirp to run on Manjaro on my Pinebook Pro (arm64). I tried snap, Flatpak and the instructions here to run the python script directly. Of course the x86 flatpak components and the lack of the required legacy Python kept it from working.

The AppImage works great with my Baofeng UV-82-HP after giving my account tty and uucp group permissions. I'll try it with my BTech GMRS-V1 and Icom IC-7100 too when I get a chance. I suggest moving ahead with AppImages until a full migration to python3 can be accomplished. I've never had an AppImage fail to function on many Linux systems over the years.

The Flatpak worked on my amd64 MX-Linux system (attempts to install the Ubuntu .deb had problems with the dependencies) and Flatpak is a no go with arm64 in many cases, I think. The snap installation (my first experience with snap) was a mess!

Thanks,

Cal AD8Q

Updated by Tony Fuller about 1 month ago

Hi Cal,

I really appreciate the feedback, especially the mention of snap not working. Could I ask if the snap version started but couldn't talk to the radio or was it a complete failure to launch?

I'm glad that you were able to get the AppImage version working on the pinebook pro.

Take care,
Tony

Updated by Calin Brabandt about 1 month ago

Hi Tony,

I'll add a snippet from my system journal that contains the snap version number (2.55.4-1) and a warning about some kernel features missing. I followed this howto:

[[https://snapcraft.io/install/chirp-snap/manjaro]]

chirp_snap never ran past the point of posting error messages to the terminal. Looking through my duckduckgo browser history, these were the issues I encountered with snap:

snap-confine has elevated permissions and is not confined but should be.

I found several reported solutions to the above (don't recall which one worked for me but it was not a persistent fix through boots) and then I encountered:

snap-confine has elevated permissions and is not confined but should be.

and finally

snap cannot change profile for the next exec call: No such file or directory

I tried a few more things, to no avail, so I gave up on snap and removed both chirp-snap and snap after the AppImage worked.

I'd be happy to reinstall snap and keep better records, if you have time to help me debug it or find the information to be useful

Cal AD8Q

May 16 00:05:42 PBPRO systemd1: Starting Snap Daemon...
May 16 00:05:42 PBPRO snapd14991: AppArmor status: apparmor is enabled but some kernel features are missing: dbus, network
May 16 00:05:42 PBPRO snapd14991: overlord.go:263: Acquiring state lock file
May 16 00:05:42 PBPRO snapd14991: overlord.go:268: Acquired state lock file
May 16 00:05:42 PBPRO snapd14991: daemon.go:247: started snapd/2.55.4-1 (series 16; classic; devmode) manjaro-arm/ (arm64) linux/5.17.5-4-MANJARO-ARM.

Updated by Calin Brabandt about 1 month ago

I need to mention that the Ubuntu .deb file (or did I download it from a Debian repository?...I don't recall) was on my HP Intel/AMD64 architecture MX-Linux laptop and not my arm64 Pinbook Pro. The chirp tarball worked great on that system though!

I'm trying to migrate all my ham radio software to my Pinebook Pro, because it's a better physical fit on the bench in my shack and I'm also working towards running mobile ham radio software and hardware (like TNCs/modems, Pat, etc.) from my PinePhone (also arm64 Linux) too.

Cal AD8Q

Also available in: Atom PDF