I have an initial albeit hackish and half-broken Gqrx snap and feel it’s the right moment to mention this here!
Some of you might have heard about snaps; for the others: it’s more of an app distribution format like .dmg on OSX or .apk on Android to ship a whole application including all its dependencies. It was introduced in Ubuntu and is available on a limited (but growing :^) number of distros. Main advantages are that upstreams can ship latest bits directly to users of older releases, and apps are confined to limit what damage they can do.
What does that mean in practice? Ubuntu 14.04+ users should have snap support by default on their system and would simply run: snap install --edge --devmode gqrx-lool
and get a Gqrx + Gnuradio + Soapy + Limesuite all build from the latest sources. snap remove it and it’s gone again. No PPAs, .deb dependencies hell and what not.
Once the snap is installed, this would list adapters detected by Soapy:
lool@ubuntu:~$ gqrx-lool.SoapySDRUtil --find
######################################################
## Soapy SDR – the SDR abstraction library
######################################################
Found device 0
addr = 1d50:6108
driver = lime
label = LimeSDR-USB [USB 2.0] XYZ
media = USB 2.0
module = STREAM
name = LimeSDR-USB
serial = XYZ
And run gqrx-lool.gqrx to get the familiar Gqrx GUI.
This is an initial snap shared in the spirit of releasing early and often, hence it comes with a number of issues:
it’s too big because it includes too much, I am including everything including headers etc.; when I was including the gnuradio docs (~194M) the snap squashfs was about 113M
it has to be installed in “–devmode” to work which basically means unconfined; amongst others I suspect a blocker is USB/PCI device access, but I have not researched this yet
I’m not correctly installing the icon for the desktop file
probably ton of random issues; I have too little experience with gnu radio and gqrx to tell which features are important
and if you wonder about the -lool suffix in the snap name and commands, this is to leave the official “gqrx” name to the true upstream
NB: I’m sometimes getting this when exiting gqrx, doesn’t seem to relate to the snap but the snap happily triggers it: *** Error in gqrx’: corrupted double-linked list: 0x0000000002e1d360 ***`
the backtrace is in libgnuradio-runtime.
I picked Gqrx as a target because IIUC it’s kind of the hello-world of SDR, but I’d be curious to read what people would like to see as snaps!
You can take a look at my Raspberry Pi binary packages to see which files are necessary to include in a self contained runtime. Qt is not included here and that may add significantly to the size if you need to include it in snap. Still, even my Mac OS X binary including Qt is no more than 26 MB.
I don’t have have any public build scripts because my procedures are also mostly hackish and manual, but I can share my notes and scripts with you. However, what I meant was that you can look in the binary packages to see which files are necessary to distribute. If that’s not enough I can send you more info, perhaps my “create bundle” script for Mac OS X can be useful.
There’s a limit, but they can still do damage to the system? Not something I’d want to use.
So this does not require root access? It’s only installed by the user and for the user?
Size should be the lowest concern. I run things from git and build myself and that requires a lot more than 200M. Probably multiple GBs.
Running as non-root users should be a major concern and/or area for improvement.
Most systems are used by one person but if you were to install a snap on a true multi-user system you could easily break things for other users and that would be very bad.
I install dmg files on mac as a user and most dmgs will do that. There are some that don’t install that way but they usually don’t get installed at all.
Not to pick on you and I think the idea of a snap is not terrible but if there’s still a chance for it to damage the system then the snap implementation is not complete or if it’s complete then it’s not proper.
It depends what permissions you grant, much like on your smartphone you might grant permission to access location / contacts / pictures to this or that app. In this specific case, the main remaining issues to good confinement are:
snaps can’t currently use fine-grained USB permissions, so if running an SDR app as root, you’d either give access to poke at all USB devices or none; if running the snap’s app as a non-root user, this would be limited further to the devices that this user can access by regular unix permissions
X11 apps are fundamentally insecure because they can snoop on X events happening outside their window; Wayland/Mir are designed to protect against this
You can install snaps as non-root, and you can run them as non-root:
snaps are installed system-wide, but there are per-user and system-wide state directories for each snap
for an user to prove that he may install system-wide snaps he needs to run “sudo snap login” once, otherwise you have to install snaps with “sudo snap install …”
I was talking to @lool about this already but just for anyone else reading along: The limenet snaps are updated for the 17.02 release. Since I wrote that blog, the snapcraft.yaml now supports environment variable, which helped to cleanup quite a bit of the environment.sh stuff. Much less hacky now. I havent heard anything about getting udev rules as a feature for snaps to grant device permissions and such, so you still need the udev rules and the --devmode.
How can a system-wide install be done as a non-root user?
I guess snaps are trying to solve the problem of getting the newest software to users with minimal impact. But the impact part of the equation is not really solved.
Snap installation is done by snapd; the snap command is a client asking it to install apps on your behalf. By default you need to sudo snap install foo, but you can prove your privileged by running sudo snap login once, and then a snap install foo is enough.
Solving distribution is one thing, and confinement is another important part – limiting what each app can do, much like on your phone.
[quote=“lool, post:11, topic:966, full:true”]By default you need to sudo snap install foo, but you can prove your privileged by running sudo snap login once, and then a snap install foo is enough.
[/quote]
Hi Larry, having snapd configured to use the LimeNET store will give you packaged versions of GNU Radio Companion, Pothos and Gqrx, with dependencies, including Lime Suite, included. Idea being that, amongst other things, it makes it much easier to distribute applications with complex dependencies, without having to worry about what version of X or Y software your Linux system has installed.
Hi Andrew, This went well until I needed to cd into the directory with snapcraft.yaml. I am too much a noob so I searched for a file named snapcraft.yaml, I have six of them.
@wb8lbz_Larry, you don’t need to build the snaps (albeit you’re welcome to); they are available to install straight from the LimeNet store; you may find instructions under the section called “Snaps for LimeSDR” on this page: https://myriadrf.org/blog/snap-packages-limesdr/
I guess I don’t understand what you are referring to. I entered the line: sudo apt-get install snapcraft snapd and the next instruction is : To build the snap, simply open a terminal and cd into the directory containing “snapcraft.yaml”. what directory is it in?
You’re following instructions from the first half of the page in the case where you want to rebuild things yourself; the snapcraft.yaml would be a file with the contents at the top of the page, or one of the source files of the MyriadRF snaps. The snapcraft.yaml files for the various MyriadRF snaps are at GitHub - myriadrf/snapcraft-sandbox: A sandbox for snaps
But instead you may simply scroll down to “Snaps for LimeSDR” and follow instructions there to install pre-built snaps and not worry about this
