Build AppImage based on conda packages #1301
Conversation
|
Until the workflow runs here, you can get the AppImage from my fork here: https://github.com/ryanvolz/gqrx/suites/16841242385/artifacts/961898081 edit: Or, I guess that will be the only place to get it until after this is merged. |
|
I'd say FreeSRP support is a low priority. The libfreesrp code has been dead since 2017 and the project didn't meet its crowdfunding goal, so I doubt there is much hardware out there. |
|
If it's any easier, SoapyFCDPP could perhaps be used for Funcube support: https://github.com/pothosware/SoapyFCDPP |
argilo
force-pushed
the
conda-app-bundle
branch
5 times, most recently
from
da2025f
to
a01a8c4
Compare
|
Notes so far:
|
Love the detailed look! I've initiated new builds of the conda-forge |
|
My attempt to run the artifact from successful workflow run on a slightly outdated system: |
|
Thanks for the testing! It looks like at some point conda-forge started shipping its own I'll investigate if there's anything to be done. |
|
If it's not too many blacklisted libraries that basing on conda-forge will require, we could try ignoring the blacklisting and manually copying them in to the AppImage. That list is 2 libraries long so far, so that's manageable. I'll see if I can work up a build for testing. |
ryanvolz
force-pushed
the
conda-app-bundle
branch
from
97ad387
to
e3a306d
Compare
|
@vladisslav2011 Please test this new build with your two missing (blacklisted) libraries included, or it will also be available as an artifact here when the CI run completes. |
|
@ryanvolz |
ryanvolz
force-pushed
the
conda-app-bundle
branch
from
e3a306d
to
a8be07e
Compare
|
This could get tedious, but @vladisslav2011 here's another one to test. |
|
Still no success: Hmmm... |
ryanvolz
force-pushed
the
conda-app-bundle
branch
from
a8be07e
to
41fd39a
Compare
|
@vladisslav2011 I tried to go maximalist this time and include all libraries that conda-forge ships: AppImage here. |
|
This one starts, but it fails to find a device and looks weird (fonts). |
The font thing might be harder to figure out, but devices should be solvable. What particular device(s) is/are we talking about? Oh, I see the edit now, |
|
Msi SDR support was re-added to gr-omosdr, so it should be possible to enable it. |
Ah yeah I missed that! So then we still need that Fonts look fine for me locally with the latest AppImage, but I do see a message from fontconfig when starting Gqrx that could point toward what is happening: I'll dig into that a little bit. I'm also now seeing which may or may not indicate something else that can be fixed. |
|
Fontconfig being unable to find its default config file has now been fixed. @vladisslav2011 curious to see if that fixes your ugly font issue. |
|
Unfortunately the fonts are still bad: |
ryanvolz
force-pushed
the
conda-app-bundle
branch
from
59449fa
to
1066db7
Compare
|
I finally got the So once the next builds complete, the only remaining thing I see is to figure out the issue with ugly fonts. |
ryanvolz
force-pushed
the
conda-app-bundle
branch
from
c2481ef
to
de104ef
Compare
|
Alright, I also tweaked the fontconfig setup so that it now loads all of the |
|
The old AppImage is definitely showing signs of age (ancient hardware drivers & Qt). I recently got a 2.17.4 release out the door, so it's probably a good time to get this merged so it will have some soak time before the next release. I'll start by rebasing to resolve the merge conflict. |
This points to the correct FONTCONFIG_PATH as well so that the conf.d files in the AppImage are read. This also removes lines in fonts.conf that refer to a prefix directory (e.g. conda prefix) that doesn't exist in the AppImage.
…ewer one" This reverts commit d1a6346.
argilo
force-pushed
the
conda-app-bundle
branch
from
cfbf7f8
to
790ff3e
Compare
|
I tested on Ubuntu 18.04 and the AppImage runs well there. @ryanvolz I get "no device found in this context" when I try to use a PlutoSDR and I suspect it could be due to a bug that was fixed in pothosware/SoapyPlutoSDR#42. There have also been a bunch of other fixes to SoapyPlutoSDR like pothosware/SoapyPlutoSDR#48, so it might be a good idea to update the conda package. (Unfortunately, SoapyPlutoSDR hasn't had a tagged release in a long time.) |
|
I removed the redundant Soapy modules and will merge this now. It would of course still be nice to get SoapyPlutoSDR updated at some point. |
I don't like doing it, but yeah, I whipped up a patch to bring the package up to the current state without waiting for a release. Packages should be available in ~30 minutes and used in any future builds. Once the dust settles, this should be extendable to make a linux-aarch64 AppImage as well. And with #1326, if a lack of MSYS2 packages for various devices is holding back the Windows binary, one could combine pulling the Windows conda packages like here with the windeployqt6 step of #1326 and get a Windows binary zip with more device support. Similarly one could probably make use of the conda packages on macOS, say for an arm64 binary. I'll be pretty busy for the next couple months, but I'd consider taking a crack at it at some point or help anyone else do so. |
|
Thanks again for working on this! I think it would be great to have a linux-aarch64 AppImage eventually, and basing the Windows and macOS binaries on conda packages would be a nice improvement as well. |
Thanks! I triggered a rebuild, and PlutoSDR now works. https://github.com/gqrx-sdr/gqrx/actions/runs/7923484733/artifacts/1251941715 |
|
By the way, I pinged the SoapyPlutoSDR folks and they tagged a release (0.2.2). |
After discussing this on the Matrix chat, here is my attempt at updating the Github Action to build the Linux AppImage based on conda-forge packages instead of Ubuntu 18.04. Conda-forge packages are built on a CentOS 6 base (with some packages potentially opting for a CentOS 7 base), so compatibility with older distributions should be maintained. The main benefit of this would be the inclusion of recent versions of Gqrx's dependencies, e.g. GNU Radio 3.10.7, UHD 4.5, etc.
As of now, there are some non-version differences in what is included with this AppImage compared to the existing one. Missing:
soapysdr-module-fcdppandgnuradio-funcube[ ] FreeSRP support (will require alibfreesrppackage for conda-forge'sgnuradio-osmosdrto be built against)gr-iqbalpackage for conda-forge'sgnuradio-osmosdrto be built against)Now including:
soapysdr-module-plutosdrsoapysdr-module-lms7soapysdr-module-netsdrlibmirisdrthroughgnuradio-osmosdrThe missing things just need a little more packaging work to enable.
I'm very interested in feedback from anyone who is able to test the resulting AppImage to make sure everything works as expected, particularly on older distributions.
One thing that is left to determine is if it's necessary to distribute the licenses of the included libraries and if there is a good way to do that from the conda-forge packages. The current method relies on running
dpkg-queryand that of course doesn't work when the library source is not a Debian/Ubuntu package.