CHIRP

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.

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

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

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.

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

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

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

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

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