Bug #9673
closedchirp python3 version
0%
Description
This is more a query than a "bug" ...
Python2 reached end-of-life a year ago (Jan/2020) and Python2 has not been supported since that time. But I think Chirp is still using python2?
I love using Chirp. It's a fantastic application and project. And as far as Python goes, although it may be a very popular programming language, having to manage all of it's parts & pieces is a HUGE PITA. So from my point-of-view myself & Python are really the problem here, and not Chirp.
I've had Chirp running just fine on Debian based disttibutions of linux (eg. Linux Mint). But these linux versions have become bloatware to me. So I have been using other linux distros (eg. Alpine, Slackware, Artix) which are smaller, faster, reliable & powerful. And in most all linux distributions, Python2 is/has been dropped.
I've tried using https://chirp.danplanet.com/projects/chirp/wiki/Linux_Python3, flatpak, and trying to debug the pile of Chirp startup error messages;
"Failed to import /home/jordi/chirp.hg/chirp/drivers/ft2900: invalid syntax (ft2900.py, line 540)"
"Failed to import /home/jordi/chirp.hg/chirp/drivers/thuv1f: invalid syntax (thuv1f.py, line 217)"
"Failed to import /home/jordi/chirp.hg/chirp/drivers/baofeng_common: invalid syntax (baofeng_common.py, line 167)"
... etc.
to try and determine which PITA Python piece(s) and/or PATHS I may be missing to try and make this Python2 program run under Python3.
So my question.. Is an actual "Chirp Python3" coded version of the program going to be available in the not too distant future?
Thanks for everything, and Happy New Year!
Jordi
Updated by Tony Fuller almost 3 years ago
Hi Jordi,
Would you be interested in either building or testing an AppImage version of chirp? The advantage here is no middle-ware (flatpak, snap, dependencies).
If you'd be interested in testing, I have builds at https://github.com/goldstar611/chirp-appimage/releases/tag/02Mar2022
If you'd be interested in building it yourself, I have notes at https://github.com/goldstar611/chirp-appimage
I'd appreciate the feedback. Thanks
Tony
Updated by Jordi Guri almost 3 years ago
Hi Tony,
I've downloaded Chirp-daily-20220227+799d07a-x86_64.AppImage onto my cheapy linux laptop (formerly a Chromebook running Chrome/OS, ASUS C202SA, price ~$200). This is now running only Gallium linux (Debian/Ubuntu based). Console terminal shows:
+++++
jordi@latte:~/Downloads$ uname -a
Linux latte 4.16.18-galliumos #1 SMP PREEMPT Sun Jun 23 04:14:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
+++++
I've made the AppImage executable and tried running it as follows:
+++++
jordi@latte:~/Downloads$ chmod a+x Chirp-daily-20220227+799d07a-x86_64.AppImage
.
jordi@latte:~/Downloads$ ls -l Chirp-daily-20220227+799d07a-x86_64.AppImage
-rwxrwxr-x 1 jordi jordi 32920768 Mar 6 10:37 Chirp-daily-20220227+799d07a-x86_64.AppImage
.
jordi@latte:~/Downloads$ . Chirp-daily-20220227+799d07a-x86_64.AppImage
bash: .: Chirp-daily-20220227+799d07a-x86_64.AppImage: cannot execute binary file
.
jordi@latte:~/Downloads$ bash Chirp-daily-20220227+799d07a-x86_64.AppImage
Chirp-daily-20220227+799d07a-x86_64.AppImage: Chirp-daily-20220227+799d07a-x86_64.AppImage: cannot execute binary file
.
+++++
That's pretty much as far as I've gotten with it. Please note that this is the very first time that I've tried to run any AppImage file. I think this is all I need to do with AppImages, but I may be missing something.
Cheers,
Jordi
Updated by Jordi Guri almost 3 years ago
Hi again Tony,
I just tried this again on my other linux laptop (2016 MacBook Air, Linux Mint), and the results are the same on this system:
+++++
jordi@java:~/Downloads$ inxi -S
System: Host: java Kernel: 5.4.0-99-generic x86_64 bits: 64 Desktop: Xfce 4.16.0 Distro: Linux Mint 20.3 Una
.
jordi@java:~/Downloads$ chmod a+x Chirp-daily-20220227+799d07a-x86_64.AppImage
jordi@java:~/Downloads$ ls -l Chirp-daily-20220227+799d07a-x86_64.AppImage
-rwxrwxr-x 1 jordi jordi 32920768 Mar 6 11:41 Chirp-daily-20220227+799d07a-x86_64.AppImage
.
jordi@java:~/Downloads$ . Chirp-daily-20220227+799d07a-x86_64.AppImage
bash: .: Chirp-daily-20220227+799d07a-x86_64.AppImage: cannot execute binary file
.
+++++
For your info ...
Jordi
Updated by Tony Fuller almost 3 years ago
Hi Jordi,
In the last step it looks like you're using a [period] [space] to start the binary file
. Chirp-daily-20220227+799d07a-x86_64.AppImage
but it should be [period] [forward-slash]
./Chirp-daily-20220227+799d07a-x86_64.AppImage
Can you try with the forward slash? Also after you mark it as executable then you should be able to double click on it from your GUI files manager/browser.
Let me know, Thanks!
Tony
Updated by Jordi Guri almost 3 years ago
..oops.. That did the trick.
I just tested a download from my Yaesu FT-65 handheld, and this re-packaged Chirp worked fine. Looks good.
However, Chirp still seems to be using Python2 (....Nooooo...). :)
I gather that AppImage will be the new Chirp packaging for linux?
Jordi
Updated by Tony Fuller almost 3 years ago
Hi Jordi,
Thanks for testing it out, I really appreciate it.
Indeed, this is just a repackaging of the full python2 version of CHIRP. There have been a number of issues opened about the current Flatpak having "end of life" messages being displayed when it's installed so I looked into other methods of packaging CHIRP. While browsing the issue tracker for Flatpak issues I found this ticket.
I don't know what Dan's plans are for the future but now he has an additional option for distributing CHIRP under Linux.
Updated by Jordi Guri almost 3 years ago
Sounds good, Tony. From the little reading on AppImage that I've done thus far, this seems like a much better way to go for Chirp distributions under linux. Plus, it's super simple to install and uninstall. A beauty.
While we're here ...
You might also like to know that I sent in another problem (see bug #9774, now closed). This is an issue which I've emailed to; chirp_devel@intrepid.danplanet.com. Basically, it looks like the Apache server needs to have "Content_Type" set for the .flatpack file. Otherwise Chrome-based browsers try to view the .flatpak file instead of downloading it. I suspect that once the Chirp website goes to .AppImage downloads, the same problem will show up with .AppImage files too. I don't know if you're involved with the chirp_dev team, but just to let you know. For your info ...
Thanks and regards,
Jordi
Updated by Jordi Guri almost 3 years ago
Re: Apache & .flatpak problem. I'm guessing that the fix might be to add the following in .htaccess for Apache:
AddType application/octet-stream .flatpak
AddType application/octet-stream .AppImage
Cheers,
Jordi
Updated by Dan Smith about 2 years ago
- Status changed from New to Rejected
Closing this as rejected as it's not a bug. See the py3 branch on git for current progress, but yes, it's still a ways off.