Anyway, yeah, going to be packaging snapd (and associated tooling) for Solus and officially supporting it soon.
Integration into the Software Center will take slightly longer and will be a post-release issue. So, soon you’ll be able to run and builds snaps on that weird not-based-on-other-distros-distro… (meaning more potential users for your snaps, like, at least 4 more people)
You may need trivial tuning in a few files in snapd to ensure the solus release is being properly reported and handled. Just let us know if you need a hand with that. Or anything else, really.
Integrating snapd into solus software center can indeed wait as it depends on snapd and (perhaps) snapd-glib or equivalent being there in the first place. Snapd itself requires at least go 1.6 and a few golang dependencies. Part of snapd is written in C and requires the C toolchain and has optional toggles on some things (specifically you can disable apparmor if you don’t offer it in your distribution). We offer bundled taballs where dependencies are vendorized (CC @mvo for the 2.27 release) for easier integration. As I said on IRC we support all kinds of packaging, including online builds, offline vendorized and offline de-vendorized so you should be okay.
We love to keep a copy of the packaging in the snapd tree in the packaging/ directory so that we can test-build and test-run it on incoming pull requests. This is a topic for the future but I just wanted to let you know.
My suggestion is as follows:
clone the tree locally and just go build cmd/snap and cmd/snapd to see that it vaguely works
try to build cmd/snap-seccomp and cmd/snap-update-ns
look at cmd/autogen.sh and please consider sending us a patch for what you’d like to see in solus.
run that and build the C parts.
Please come back with any errors you may run into.
EDIT: You may also want to edit cmd/cmd.go and dirs/dirs.go and customize the expectations there. Look for "arch" of "fedora" for ideas.
OK so ending the work day here. Got snapd packaged up locally, systemd units, etc, all work.
Can use snap install to install things fine. Locally I’ve had to patch it to not re-exec, however I’m not entirely sure what that entails, and would ideally like to fully support it. I’m assuming this is apparmor confinement model?
Also running into an execvp issue locally which I’m debugging:
/snap/bin/hello-world
2017/08/09 17:00:51.349635 cmd.go:66: DEBUG: re-exec not supported on distro "solus" yet
execv failed: No such file or directory
Lastly I should point out this is with 2.26.8 as there is currently no _vendor tarball uploaded for 2.26.14
yeah … i’d suspect more an issue with the loop mounting of the squashfs or some such, or missing of the “current” link (though you should see an error when installing then)…
did the core snap get properly installed alongside the hello-world snap when you initially installed hello-world ?
While we add /snap/bin to the users PATH, you called the command as /snap/bin/hello-world so there shouldnt be anything missing (the execution of the snap will then happen inside core where all paths should be fine)
Can you please check with strace what’s the path that is failing to execvp? Perhaps there’s a binary missing under /usr/lib/snapd.
Also, any particular reason for disabling re-exec? The idea there is making sure that the outside snapd and the core snap remain in sync, so that the latest features supported in snaps work without you having to do anything locally.
i think the initial focus is to have a “deb” of snapd (well, whatever the equivalent on solus is) … then we can move on with re-exec, fixing the missing kernel bits and all the bells and whistles
Yes - the binary times out forever ™ so I don’t know what it’s actually meant to be doing. We’re taking it one bit at a time as @ogra pointed out - and the initial bits themselves aren’t working. Can’t strace the binary as it fails with setuid issues
Seeing lots of errors with many snaps that depend on libselinux and it’s not part of core or the snaps:
/snap/brackets/2/usr/lib/x86_64-linux-gnu/glib-2.0/gio-querymodules: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory
g_module_open() failed for /snap/brackets/2/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ani.so: libselinux.so.1: cannot open shared object file: No such file or directory
g_module_open() failed for /snap/brackets/2/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-bmp.so: libselinux.so.1: cannot open shared object file: No such file or directory
...
/snap/brackets/2/opt/brackets/brackets: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory
Depending on host-side tools that are non-standard:
/snap/brackets/2/usr/sbin/update-icon-caches: line 16: gtk-update-icon-cache-3.0: command not found
The correct command is gtk-update-icon-cache - perhaps this dependency on package-based renaming/links of tools should be documented?
Edit: I can happily patch the icon cache boog, but I think the libselinux should be coming from core really (given I’m not using selinux LSM and have no need for it in Solus - and have no interest in making it available in the repo given the way it latches itself onto every darned package going)
We’ve gotten to the point where classic snaps and --devmode snaps run fine (Solus will be going with /snap tree for maximum Snap support). Also identified some libseccomp issues and our next step is to enable AppArmor in the Solus linux-current kernel using the Ubuntu 4.13->4.12 backports.
As a nice extra, it turns out the “arch nvidia” approach works for Solus too. So yay.
)