Hi Kevin,

I created the original flatpak build script and I'm currently trying to get the updated one from Dan to bump the SDK version. You are more than welcome to try the original script at https://gist.github.com/goldstar611/cb0037ee29ae315bb2f0211e69d95799

Are you looking to build an ARM version for something like a raspberry pi? I'd love to know how it works for you.

Tony

Tony:
Yes, my intent was to get a version to build/install for Arm7 or Arm8 on RaspberryPi. A long time ago, it used to work.
At this point, I'd prefer to get/build/test a Docker version, I think. I have many docker capable machines, from RPi3s through RPi4-4GB & RPi4-8GB to many Intel, and AMD machines running *nix, Win10, and VirtualBox hosts.
If I were a programmer, I'd be happy to jump in and help, but, alas, I am but a beta tester, and try to work as an Enterprise level IT Help Desk (so I could help support it that way, like I do with motionEye/motionEyeOS)

Kevin -- KD9EFV

The link includes a Makefile :) I'm confident that if you have a raspberry pi and are comfortable using docker you can get it building. I have a pi4 that's sitting idle right now I'll test it there too.

3 months ago I might have tried building flatpacks (other than finding it didn't work for me then) but I have the infrastructure internally to make use of docker images that fits my environment, both at home and for apps I support. Unless you have a step by step example (either you wrote or can post a link to) I will probably put this on a back burner for now, and continue to try to build the docker, as it will run in its own virtual environment without requiring changes to the host like GTK and other specific version apps required.

Ok so good news and bad news.

Good news:
I have the flatpak building on a pi4 in 32bit mode (because my OS is 32bit). It uses the EOL 19.08 runtime.

Bad news:
32-bit ARM flatpak support will not be maintained, only 64-bit ARM flatpak support. And I'm not talking about chirp, I mean the flatpak infrastructure is going to drop 32-bit support.
I'm asking for more information at https://github.com/flathub/flathub/issues/2878

Doesn't surprise me any, especially after the RPi Buster to Bullseye fiasco. I don't see other SBCs doing any better, either. Good thing about Docker is I can build the internal mechanism for i386 or armhf, or AMD64 to run most apps for the first 2 without consideration as to the docker host. I just did a clean install of chirp on a debian10-64 in a VM, installed CHIRP daily 2022-0219, and it's working. I now just need to create the same thing in a docker.

For grins and giggles, I tried to install the chirp flatpak on DanPlanet, in Debian 11 Desktop, and got dependency warnings. I thought the purpose of flatpaks were to sandbox, and include all needed dependencies?

I thought the purpose of flatpaks were to sandbox, and include all needed dependencies?

Yes flatpaks do sandbox apps and include dependencies. But as I learned, a lot of gnome/gtk dependencies come from the gnome developers in the form of a "runtime." This runtime lets us focus on building the app, not compiling the entire GUI stack from source. It appears that rather than leave an old working SDK and platform in the flathub they may remove it at somepoint :(

IMO, for what its worth, another reason to forsake flatpak, if they are going to randomly break things, remove what had been default inclusions, etc. It's like they went to the same school as the RPiFoundation, breaking/removing things without consideration to the people that use it. If I want to have to dig through all the documentation to re-include the missing runtimes, dependencies, etc, I might as well stick to what works, more or less, the tarball and its dependencies in a clean install.
Of course, it would be handy to have a list of the other dependencies, like python-gtk and so forth in the README file, maybe...

So flatpak, and the gnome developers, won't change or break things, per se, but they may decide to remove "old" or "end of life" stuff at any moment. To me, that's life.

A dependency list would be helpful with links to download the source files so they can be compiled if/as necessary. I have that on a to-do list somewhere.

At any rate I was able to finally succeed in getting a chip appimage building for amd64, aarch64 and armhf. Would you be interested in testing it out? A normal desktop computer can build all 3 architectures. At the bottom of the YML file is where you tell AppImage which architecture to build. I'm still trying to figure out how to build them all at once. There are instructions in the readme on getting the tools working.

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

It works on my desktop and my raspberry pi 4 (32 bit OS) for a Baofeng 888 radio.

What would be prefered? I have a nice little VBox host with Master Images of Debian 9, 10 & 11 Desktops & servers, Ubuntu 18.04, 20.04, 21.04, & 22.04 desktops and servers, Arch (about 2 months old) and can throw up anything else without too much effort. My RPi4s (4GB and 8GB) can be used tomorrow. I have a couple of i386 Master Images, too, that I use for building my own custom RPi Images using their (RPiFoundation's) PiBuild scripts regularly.
Another issue, though, is what is needed to install / use an AppImage? To use / install a flatpak requires 125MB worth of other stuff to be installed, plus it would help to give novice users the command line to install it (I didn't see anything like that in the DanPlanet stuff, but may have missed it. I re-wrote the Docker install instructions for motionEye on Docker to help novices use a docker image: https://github.com/ccrisan/motioneye/wiki/Install-In-Docker Something like this would be helpful for AppImage going forward. All the instructions for the various flavors of motionEye are templated, and I supported and found the new instructions for the python2 pip2 when the upstream people killed it.
Let me know how I can help.

What would be prefered?
I still have an action item to test out the flatpak on the newer runtime, there's no updated one as of yet. Another verification on the AppImage would be super helpful. If you can't get it building I will just upload it to github as a "release" for now.

Another issue, though, is what is needed to install / use an AppImage?
To use an appimage you just mark it as executable and then double click on it. To build an AppImage you need some infrastructure. The AppImages are more than 5MB so I can't attach them here.

To use / install a flatpak requires 125MB worth of other stuff to be installed, plus it would help to give novice users the command line to install it (I didn't see anything like that in the DanPlanet stuff, but may have missed it.
Correct, Dan is not distributing AppImages yet. They need some testing first :)

I re-wrote the Docker install instructions for motionEye on Docker to help novices use a docker image: https://github.com/ccrisan/motioneye/wiki/Install-In-Docker Something like this would be helpful for AppImage going forward. All the instructions for the various flavors of motionEye are templated, and I supported and found the new instructions for the python2 pip2 when the upstream people killed it.
Documentation at this level would only be needed for developers or those wishing to create their own AppImage. Chirp Linux users would not need to know anymore than how to run chomod 755 chirp.appimage from a command line.

Let me know how I can help.
It's greatly appreciated :)

OK, problem in motionEye confirmed to be end user error.

My test-build environment:
Debian 11, 4GB RAM / 50 GB Drive XFCE Desktop Current full update

Update in-app version¶

LATEST_COMMIT_DATE=$(git log -1 --date=format:"%Y%m%d" --format="%ad")
LATEST_COMMIT_SHORT=$(git rev-parse --short HEAD)
CHIRP_VERSION="daily-${LATEST_COMMIT_DATE}+${LATEST_COMMIT_SHORT}"
sed -i "s/CHIRP_VERSION = \".*\"/CHIRP_VERSION = \"${CHIRP_VERSION}\"/" chirp/init.py

Install chirp¶

python2.7 setup.py install --prefix=/usr --root=../AppDir
bash: line 14: python2.7: command not found
Traceback (most recent call last):
File "/usr/local/bin/appimage-builder", line 8, in
sys.exit(main())
File "/usr/local/lib/python3.9/dist-packages/appimagebuilder/main.py", line 58, in main
invoker.execute(commands)
File "/usr/local/lib/python3.9/dist-packages/appimagebuilder/invoker.py", line 41, in execute
command()
File "/usr/local/lib/python3.9/dist-packages/appimagebuilder/commands/run_shell_script.py", line 64, in call
raise RuntimeError("Script exited with code: %s" % _proc.returncode)
RuntimeError: Script exited with code: 127

python2 required, python2 not installed in default clean Debian 11, need to add it to your 1st block.
Doesn't hurt if already installed.
Debian 11 has no 'default' python, either.
python --version: command not found.
python2 --version: command not found.
python2.7 --version python 2.7.18
python3 --version python 3.9.2
pip --version pip 20.3.4 from /usr/lib/python3/dist-packages/pip (python 3.9)
pip2 --version command not found
Which one(s) are needed? More than just python2.7 (same errors as above) and which defaults? Is pip2 needed?

ah I see, yes I am using python2.7 to install chirp into a special directory.

I will add that to my first block as python2.7-minimal

This is great feedback!

May want to use something besides python2.7 for that. Since 2.7 was deprecated, EOL'd and removed from most repos, it's going to be harder and harder to change it later...