Packaging snapd for Solus


#1

Lemme start off by blaming a few people… :stuck_out_tongue:

  • @Wimpress - for finally making me realistically consider Snaps
  • @zyga for making me post this xD

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 :open_mouth:)


#2

Eh, just realised I didn’t introduce myself. Derp!

I’m Ikey Doherty, lead/founder of Solus, creator of the Budgie Desktop, etc. bows


#3

Welcome to the team, and that sounds great!

I assume this is about solus-project.com, right?

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. :slight_smile:


#4

Hey! Welcome :slight_smile:

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.


#5

Indeed :slight_smile: Thanks - will report any issues I encounter. Right now I’ll focus on just getting the super-basic-package before refining it.


#6

This is really great, thanks for undertaking the work to bring snaps to Solus @ikey.


#7

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


#8

you could try to install hello-world with the --devmode flag … that way it will ignore apparmor, seccomp etc …


#9

Same thing happens - not confinement related it would seem


#10

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 ?


#11

Yep core snap is there and the current link is set up, so I’m wondering if its some kind of naive $PATH assumption somewhere.


#12

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)


#13

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.


#14

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


#15

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


#16

@ikey can you please list all of the files belonging to the snapd package your made?


#17

New version of snapd fixed the issues so far:

 ✓  ufee1dead@ironhide  ~  snap run hello-world
2017/08/09 20:24:54.064087 cmd.go:71: DEBUG: re-exec not supported on distro "solus" yet
Hello World!
 ✓  ufee1dead@ironhide  ~  

 ✓  ufee1dead@ironhide  …/Solus/snapd   master ?  lseopkg snapd-2.26.14-1-1-x86_64.eopkg 
/usr/bin/snap
/usr/bin/snapctl
/usr/lib/udev/rules.d/80-snappy-assign.rules
/usr/lib/udev/snappy-app-dev
/usr/lib64/snapd/info
/usr/lib64/snapd/snap-confine
/usr/lib64/snapd/snap-discard-ns
/usr/lib64/snapd/snap-exec
/usr/lib64/snapd/snap-seccomp
/usr/lib64/snapd/snap-update-ns
/usr/lib64/snapd/snapd
/usr/lib64/snapd/snapd.core-fixup.sh
/usr/lib64/snapd/system-shutdown
/usr/lib64/systemd/system/snap-repair.service
/usr/lib64/systemd/system/snap-repair.timer
/usr/lib64/systemd/system/snapd.autoimport.service
/usr/lib64/systemd/system/snapd.core-fixup.service
/usr/lib64/systemd/system/snapd.refresh.service
/usr/lib64/systemd/system/snapd.refresh.timer
/usr/lib64/systemd/system/snapd.service
/usr/lib64/systemd/system/snapd.socket
/usr/lib64/systemd/system/snapd.system-shutdown.service
/usr/lib64/systemd/system/sockets.target.wants/snapd.socket
/usr/lib64/tmpfiles.d/snapd.conf
/usr/share/man/man5/snap-confine.5
/usr/share/man/man5/snap-discard-ns.5

#18

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)


#19

Status update …

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.


#20

Another update…

Solus kernel now has full AppArmor implementation (i.e. full like Ubuntu) https://plus.google.com/+Solus-Project/posts/i6wdUSUbLEk