Please provide an AppImage for Linux on GitHub Releases

[probonopd]

Providing an AppImage would have, among others, these advantages:

• Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions
• Can be listed in the AppImageHub central directory of available AppImages
• Can double as a self-extracting compressed archive with the --appimage-extract parameter

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

[f4exb]

It could be interesting but it looks like a fairly large undertaking. This is not the priority for the moment.

[f4exb]

I am expecting contribution on this. I have many more important things that need attention so I will not spend time on this.

[probonopd]

Thanks for your response @f4exb, I read this as "if someone sends a PR that will produce an AppImage and upload it to GitHub Releases, it will be considered". I think I can give you a hand, but may need occasional help from you if I'll run into any issues building this, and when it comes to the "final polish" to make sure everything works as intended.

[probonopd]

Succeeded building an AppImage, it can by downloaded from https://github.com/probonopd/sdrangel/releases. Built using https://github.com/probonopd/sdrangel/blob/patch-1/.travis.yml.

However, on Clear Linux OS I get

user@host ~ $ Downloads/SDRangel-49ffdf7-x86_64.AppImage 
terminate called after throwing an instance of 'std::regex_error'
  what():  regex_error
Aborted (core dumped)

when trying to run it. What could be causing this?

LD_DEBUG=libs strace -f squashfs-root/AppRun >log.txt 2>&1 attached.

log.txt

[probonopd]

Same on Xubuntu 18.04:

me@host:~$ Downloads/SDRangel-49ffdf7-x86_64.AppImage 
terminate called after throwing an instance of 'std::regex_error'
  what():  regex_error
Aborted

me@host:~$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic

[probonopd]

I need help on these errors @f4exb so that I can continue.

[f4exb]

Would it be possible for you to get a stack trace at the time of error so I can get an idea of the path taken? The strace is not really helping.

[probonopd]

How exactly would I do that?

[f4exb]

Just as usual: compile with debug symbols, open the core dump with gdb and use "bt" command. I don't know how this can apply with your appimage thing, this is your business. This is very easy when you compile from source.

[probonopd]

AppImage is just a self-mounting filesystem, it does not change what one puts inside (like a zip or ISO file).

[f4exb]

If it is just that then why would it fail like this in the first place? I never encountered such an issue.

[probonopd]

Think of an AppImage like a zip or iso file. It's just an archive that holds whatever you put inside. I don't think the issue here is AppImage specific.

[f4exb]

With the little information given by strace we know that this std::regex_error is thrown in libsdrbase.so. There are not many instances of std::regex there so it should be somewhere here: https://github.com/f4exb/sdrangel/blob/master/sdrbase/webapi/webapiadapterinterface.cpp#L38

Apart from the fact I see nothing wrong with these regex definitions this code is executed each time the program is run (this is static). There are no issues when compiling from source or with the code built in the .deb packages.

How do you explain this? What do you "put inside" actually? Wouldn't it be an issue with the standard C++ library you put inside?

[probonopd]

Possibly, I don't know. If you'd like what is inside, then please download the AppImage from https://github.com/probonopd/sdrangel/releases and extract it like so:

wget -c "https://github.com/probonopd/sdrangel/releases/download/continuous/SDRangel-49ffdf7-x86_64.AppImage"
chmod +x ./SDRangel-*-x86_64.AppImage
./SDRangel-*-x86_64.AppImage --appimage-extract

You can then freely inspect its contents.

If you would like to see how the AppImage was produced, this is how:
https://github.com/probonopd/sdrangel/blob/patch-1/.travis.yml

[f4exb]

OK, even without debug symbols the stack trace gives some information confirming that the system libstdc++ is used. So I still don't see why it would fail:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007f5d3c5c4801 in __GI_abort () at abort.c:79
#2  0x00007f5d3cc198b7 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007f5d3cc1fa06 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007f5d3cc1fa41 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007f5d3cc1fc74 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007f5d3cc1b91f in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00007f5d3e1803cb in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_bracket_expression() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#8  0x00007f5d3e1806fa in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_atom() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#9  0x00007f5d3e181480 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_disjunction() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#10 0x00007f5d3e180d7a in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_atom() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#11 0x00007f5d3e18129a in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#12 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#13 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#14 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#15 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#16 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#17 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#18 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#19 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#20 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#21 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#22 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#23 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#24 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#25 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#26 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#27 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#28 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#29 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#30 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#31 0x00007f5d3e181300 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_alternative() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#32 0x00007f5d3e1814e8 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_M_disjunction() () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#33 0x00007f5d3e181a21 in std::__detail::_Compiler<char const*, std::regex_traits<char> >::_Compiler(char const* const&, char const* const&, std::regex_traits<char>&, unsigned int) ()
   from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#34 0x00007f5d3e181fc8 in std::shared_ptr<std::__detail::_Automaton> std::__detail::__compile<char const*, std::regex_traits<char> >(char const* const&, char const* const&, std::regex_traits<char>&, unsigned int) ()
   from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#35 0x00007f5d3e1825f1 in std::basic_regex<char, std::regex_traits<char> >::basic_regex(char const*, unsigned int) () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#36 0x00007f5d3e082438 in ?? () from /tmp/sdrangel.appimage/squashfs-root/usr/bin/../lib/libsdrbase.so
#37 0x00007f5d3e9af733 in call_init (env=0x7ffd55d821d8, argv=0x7ffd55d821c8, argc=1, l=<optimized out>) at dl-init.c:72
#38 _dl_init (main_map=0x7f5d3ebc8170, argc=1, argv=0x7ffd55d821c8, env=0x7ffd55d821d8) at dl-init.c:119
#39 0x00007f5d3e9a00ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#40 0x0000000000000001 in ?? ()
#41 0x00007ffd55d833b1 in ?? ()
#42 0x0000000000000000 in ?? ()

[probonopd]

Let's cc some C++ wizards, @TheAssassin, @azubieta ;)

[f4exb]

There could be a library mismatch. I see "dist: trusty" in the yml file (i.e. Ubuntu 14.04). If this is actually the case then this is probably a very old version.

Found something interesting here on the provided libsdrbase.so:

objdump -p usr/lib/libsdrbase.so
 ...
Version References:

  required from libgcc_s.so.1:
    0x0b792650 0x00 16 GCC_3.0
  required from libQt5Network.so.5:
    0x00058a25 0x00 09 Qt_5
  required from libm.so.6:
    0x09691a75 0x00 12 GLIBC_2.2.5
    0x06969195 0x00 08 GLIBC_2.15
  required from libc.so.6:
    0x0d696914 0x00 13 GLIBC_2.4
    0x09691a75 0x00 10 GLIBC_2.2.5
    0x06969194 0x00 07 GLIBC_2.14
  required from libstdc++.so.6:
    0x0297f864 0x00 19 GLIBCXX_3.4.14
    0x02297f89 0x00 18 GLIBCXX_3.4.9
    0x0297f869 0x00 17 GLIBCXX_3.4.19
    0x0297f861 0x00 15 GLIBCXX_3.4.11
    0x0297f865 0x00 11 GLIBCXX_3.4.15
    0x056bafd3 0x00 06 CXXABI_1.3
    0x08922974 0x00 05 GLIBCXX_3.4
  required from libQt5Gui.so.5:
    0x00058a25 0x00 04 Qt_5
  required from libQt5Multimedia.so.5:
    0x00058a25 0x00 03 Qt_5
  required from libQt5Core.so.5:
    0x058a2819 0x00 14 Qt_5.9
    0x00058a25 0x00 02 Qt_5

[f4exb]

Another trail: if "trusty" is really used then GCC 4.8.2 is used according to Travis documentation and this gcc may not implement std::regex properly.

[TheAssassin]

GCC 4.8+ implemented C++11 completely, except for <regex>. Support for that was introduced in GCC 4.9. You cannot use <regex> on Ubuntu trusty. The only way is to use some super outdated packages providing a newer GCC version (e.g., this ubuntu-r-toolchain-something), but they also require a more recent libstdc++, so you break compatibility with trusty anyway. If you need it, I'd recommend to build on some more recent Debian (old)stable, or e.g., xenial.

[probonopd]

But then it won't run on all still-supported versions of Ubuntu. Which is why we recommend to build on trusty. If we absolutely must use a newer compiler and/or libstdc++ than what comes with trusty, then we need to bundle it and use https://github.com/darealshinji/AppImageKit-checkrt/. I will try that now.

https://github.com/AppImage/AppImageKit/wiki/Creating-AppImages#libstdcso6

[f4exb]

In fact this issue ahs been already encountered and the main cmake file was updated accordingly:
https://github.com/f4exb/sdrangel/blob/master/CMakeLists.txt#L4

So if you are using it you should not be able to complete the cmake step.

[probonopd]

Using gcc-8 from ubuntu-r-toolchain-something now: probonopd@4c02f83

[TheAssassin]

JFYI: Using any other compiler toolchain also means using a newer libstdc/libstdc++ which means you break compatibility with the system you're on.

[probonopd]

At least for libstdc++ I am taking care of... how do you do this for libstdc?

[TheAssassin]

How would you handle this from libstdc++? Bundle it?

Just build it on xenial... trusty is going EOL in 4 months anyway, it's not worth the effort any more IMO. That was different half a year ago, but now...

[probonopd]

How would you handle this from libstdc++? Bundle it?

  - ./linuxdeployqt-continuous-x86_64.AppImage appdir/usr/share/applications/*.desktop -bundle-non-qt-libs
  - mkdir -p appdir/usr/optional/ ; wget -c https://github.com/darealshinji/AppImageKit-checkrt/releases/download/continuous/exec-x86_64.so -O ./appdir/usr/optional/exec.so
  - mkdir -p appdir/usr/optional/libstdc++/ ; cp /usr/lib/x86_64-linux-gnu/libstdc++.so.6 ./appdir/usr/optional/libstdc++/
  - ( cd appdir ; rm AppRun ; wget -c https://github.com/darealshinji/AppImageKit-checkrt/releases/download/continuous/AppRun-patched-x86_64 -O AppRun ; chmod a+x AppRun)
  - ./linuxdeployqt-continuous-x86_64.AppImage appdir/usr/share/applications/*.desktop -appimage

Do we need to do a similar thing for libstdc?

[f4exb]

This is to be superseded by Docker. See: https://github.com/f4exb/sdrangel-docker

[alexmyczko]

Debian/Ubuntu users might prefer a native package: http://phd-sid.ethz.ch/debian/sdrangel/

[TheAssassin]

An AppImage is more user friendly, though. It doesn't need any sudo stuff or installation or anything. Not every host has Docker, and Docker isn't quite made for bundling end-user applications. Now that it's April, I hope that not even @probonopd has any issues if stuff isn't compatible with trusty any more... (wasn't half a year ago either, but well).

[f4exb]

Two falsehoods:

• "Not every host has Docker": all Linux hosts can have Docker it is very easy to install. I don't care much about other OSes. It can still work on other systems with some limitations.
• "Docker isn't quite made for bundling end-user applications": really? It works very well with SDRangel.

I don't mind anybody trying to bundle SDRangel in whatever format I will just not actively support it. With Docker the code and its closest dependencies can be built from source in a fully controlled environment. Compiling from source can provide all the features without bothering of packaging these close dependencies. Appimage, Snaps or package bundles fall short of these expectations.

[TheAssassin]

When talking about falsehoods, let's talk about yours, too.

"Not every host has Docker": all Linux hosts can have Docker it is very easy to install. I don't care much about other OSes. It can still work on other systems with some limitations.

What I was talking about is: not every Linux host does have it installed. Not every user can install it (think of university computers or environments like FabLabs or other open workshops where there's no root access). You'd laugh if you knew how many users, also in corporate environments, just don't have permission to use Docker or anything. BYOD is not standard, and not always the best way.

"Docker isn't quite made for bundling end-user applications": really? It works very well with SDRangel.

It's way harder to use applications with Docker. Let's assume you don't have to build it, but less tech-savvy users will struggle a lot to gain the required amount of knowledge to handle Docker.

Compiling from source can provide all the features without bothering of packaging these close dependencies. Appimage, Snaps or package bundles fall short of these expectations.

Most apps which exceed "hello world" are built in Docker containers, too. The end result is an AppImage, not a Docker image. That doesn't make the build less reproducible. You just provide scripts which automate the process, and anyone who's tech-savvy enough can just run that instead of docker build .. Already built Docker containers aren't in any way "more transparent" to the user than e.g., AppImages, you also have to trust someone to not include anything evil in there.

If you intend to allow people to produce binaries themselves, then AppImage isn't any less suitable than Docker. Quite the opposite.
How you use Docker for making AppImages is up to you, it's not like you have to use system-provided resources. You already had set up building all dependencies yourself instead of relying on distro-provided resources. Now, there's no reason why not to put them into an AppImage.

Then, let's talk about usability. I guess you don't quite realize yet that there are very many users which are not developers or experts in usability.

Did you ever read your lengthy README on the Docker environment stuff? Who, except for experienced users or even developers who ever used that technology, is willing to run all this setup and preparation to then be ready to set up SDRangel?

I do like Docker a lot, trust me, but please, compare these two UXes:

a) clone repo, run docker-compose (if it's already in there, the README says otherwise), build everything (might take hours on a less powerful machine), then run things with complex commands and hope it will be compatible to your desktop. That's pretty much why Average Joe doesn't use Gentoo or Arch's AUR.

b) download AppImage, make it executable (if you don't have AppImageLauncher yet), double click -> app is up and running.

No matter whether it's AppImage or whatnot, in comparison, Docker is a way more complex tool that, while being able to ship UI apps, doesn't really do the job well, and requires a lot of preparation and setup to even get started with setting up SDRangel. All these special things to think about (what graphics card do I have, ...), that's when you start thinking "do I really want to go through this to use the application?".

I also had to change my mindset when starting to get into AppImages, focusing on the user more than on ease of development. In the end, you want to reach as many users as possible, and you want to make it easy for them. Things like "can build your own infra" are nice to have and very important for some people, but Average Joe doesn't give very much on it. They just want to get things up and running.

Even though SDRangel is more for "experienced users", this is more for SDR, not for knowledge on Linux systems.

I know the discussion about the AppImage base build system and all that might have been a bit annoying, but hey, IMO it doesn't matter that much where you build it. Sure, it's nice if people with older distros who e.g., can't upgrade (again, university labs, open workshops, ...), can run the app, but if you say "that'll be too much work to maintain, I'd rather move on", that's a completely valid choice IMO. Especially when beginning to develop an application or start to make AppImages.

Please don't get me wrong, I do like your app and I am definitely biased. I just want you to think a bit more on the topic before going for a direction that will end up in people not being able to use the latest versions. That's also negative for you; there's nothing more annoying than getting issues for outdated versions that might e.g., be in distribution repos, when you know the bug has been resolved already in a newer version...

If you decide to go for Docker and drop all other options, by the way, it's really unrealistic you'll find maintainers for other ways of distribution other than maybe inclusion in distro repos. The build process and everything is very complex, and also since these are third party bundles, people are reluctant to using them anyway.

[f4exb]

SDRangel is open source software. This is not free software. Be ready to pay something not in hard cash but rather in sharing a tiny bit of the effort put into this project. People gradually forgot that originally "free" was free as in freedom and take free as in free beer (or lunch) this is why I will avoid the term. However freedom with this project is real.

I am not against people packaging SDRangel in any way they may like. This is open source. You have the source you know how to compile it and package the stuff this is all good. However I am not ready to solve issues directly related to the packaging process. If you see something wrong in the code along the way then of course I am willing to fix it but I will not make any effort in investigating problems related to packaging or issues related to the packaged versions.

Eventually if you have radical different views on this project you may also fork it to your own.

There are some contributors to various extents to this project and I am grateful of the time and energy they put into it. However let's face it: I am the main developer of this project making the essential new features happening. I am a single developer and this is not my day job and I do not get paid with hard cash for it. I am enthusiast about software development and radio and my reward is to enjoy what I am doing with this project. Other projects may have entire teams dedicated to maintenance.

Many open source projects end up by exhaustion of their main contributors. "Dockerization" is an attempt to avoid this with SDRangel or make it happen as late as possible. In order to respond swiftly and efficiently to real issues I need a tighlty controlled environment where issues can be reproduced. With some complex libraries that are easier to build from source this is also a good way to provide some new features painlessly. Docker provides just that and today is the best option to reduce the "it works on my machine" syndrom. Ubuntu snaps are the only thing that may come close.

"Docker is too complex", "I don't know how to install Docker", "Docker is not made for end users"... this is all rubbish. The complexity is in the Dockerfile and this has been written for you. This Dockerfile is also open sourced and can be amended and contributed.

See this example from someone who did not have previous knowledge of Docker but was curious enough to just try it:
https://groups.io/g/sdrangel/topic/sdr_angel_docker_update/30795948?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,30795948

My bottom line is the third paragraph: if you don't like SDRangel the way it is and have a radical different view then fork it to your own.

[probonopd]

I am going to close this feature request since the upstream author has chosen not to provide an official, upstream-packaged and upstream-supported AppImage. No need to be mad at each other.