CHIRP

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

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

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

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

..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

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.

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

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