CHIRP

Daniel Rusek wrote:

I plan to start working on CHIRP Flatpak and publish it on Flathub. Please let me know if you would be interested in making such Flatpak an official one and co-maintain it. Thanks!

The other possible solution could be distributing the *.flatpak files for CHIRP-next directly on the CHIRP website (instead of the .whl file that is useless for most common users), just like they are distributed for the CHIRP-legacy build, and including a gpg-signed Flatpak remote in these files so the CHIRP-next Flatpak could get updated automatically. I can provide help if needed.

I found out that there was an unofficial AppImage for CHIRP-next:

https://github.com/goldstar611/chirp-appimage

Sadly, its GitHub repository has been archived and new builds are no longer being made.

Maybe something similar, but official, could be even better than the Flatpak?

This probably should have started off as a question/comment on the Developer mailing list. I would suggest that you make you intentions known there.

Just FYI I'm really not interested in maintaining official flatpak, appimage, etc stuff. If someone else wants to, that's cool, but that's the only way it will happen.

I have probably changed my mind and won't be creating the CHIRP-next Flatpak myself. Anyway, I can still offer help if someone else will be interested in working on it or on the AppImage. I am not registered on the CHIRP Developer mailing list, but it would be great if someone could forward my messages (and/or a link to this ticket) there. Thanks!

One more thing: I was thinking about the AppImage vs Flatpak distribution of CHIRP-next. They both have their upsides and downsides:

• Flatpak: There already is an official Flatpak manifest and build infrastructure available for CHIRP-legacy, so in theory the only thing needed is updating it to (and integrating it with) CHIRP-next. Flatpaks are very user-friendly and easy to deploy on most distros (except for Ubuntu that has basically no Flatpak support - but CHIRP-next is already available there as a Snap). Flatpaks are usually very similar to regular packages in terms of their maintenance, updates etc.
• AppImage: There already is an unofficial AppImage Git repo (with all the needed manifest files and build automation) for CHIRP-next that was last updated in 2023, but in theory should be very easy to update. It works fairly well, just needs some minor adjustments and bundling a lib or two to make it work out-of-box on modern distros such as Fedora (Siverblue) or even Valve SteamOS. AppImages are usually updated manually by downloading the *.AppImage file and replacing an old one with it; users can also have multiple versions of the same app on their system.

As I already said, I can provide help with this if needed. Feel free to contact me.

Sorry, small typo in the AppImage info: was last updated in Jul 2024 (not 2023)

I have subscribed to the "Developers" mailing list and tried to send my message (both using my e-mail client and the web ui), however it did not appear in the archive. It probably needs some kind of manual approval.

I see four identical messages from you in the rejection log. Not sure why, I'll have to go look. However, reading them, I'm not sure what the point is, other than to announce that you're not going to work on it, which I think is probably not that important to get to the list.

There are several flatpak/appimage/whatever requests open here on the tracker, which means I really should have already closed this a a duplicate. I understand that this is something you want, but it's not something I'm interested in working on. TBH, supporting Linux has become quite a point of frustration for me lately, especially with as broken as wx/gtk on wayland seems to be. Perhaps I should just take it off the list of supported OSes, but I hate to do that.

I appreciate your offer to help, and I think this and the many related tickets here are more than enough advertisement if someone is looking to coordinate that project and needs volunteers.

Yeah, I have sent the message four times during the last week. Sadly, none of the messages got approved.

I'm not sure what the point is, other than to announce that you're not going to work on it

My point was to start a discussion and maybe also motivate someone from the community or core developers to consider working on the Flatpak or AppImage distribution of CHIRP-next. I won't work on it myself as I stated before, but I can offer significant help.

I understand that this is something you want

To be honest, I personally do not have a problem using self-compiled version of CHIRP and handling the dependencies, udev rules etc. myself. But many fellow Linux using ham friends who are more common users do not have such knowledge. And sadly, the state of CHIRP packaging in most Linux distributions is not good. It either is in distribution repositories in ancient version (with only good exceptions being Fedora RPM, Ubuntu Snap and maybe ArchLinux AUR) or is not packaged at all. Most hams I know rather run CHIRP inside a Windows vm than trying to get it working natively.

TBH, supporting Linux has become quite a point of frustration for me lately, especially with as broken as wx/gtk on wayland seems to be.

Well, at least the different wx/gtk library versions and other version-specific issues would be worked around by using Flatpak with the same lib versions between all distributions as part of a Flatpak runtime or AppImage with bundled libs.

I appreciate your offer to help, and I think this and the many related tickets here are more than enough advertisement if someone is looking to coordinate that project and needs volunteers.

Fair enough. Thanks for your time and your reply!