Snapcraft - my first snap issues

Hey everyone, just installed snapcraft on Solus (compiled it from github, latest tarball 2.33)

Have it running and done the init, put in the hello-world tarball, set it to autotools and ran snapcraft but nothing, so ran with -d and only get the following:
justin@desktop ~/Builds/snaps $ snapcraft -d
Starting snapcraft 2.33 from /usr/lib/python3.5/site-packages/snapcraft-2.33-py3.5.egg/snapcraft/cli. Setting up part 'gnu-hello' with plugin 'autotools' and properties {'plugin': 'autotools', 'source': 'http://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz', 'stage': [], 'prime': []}.

Snapcraft.yaml for reference: https://hasteb.in/ijayutanoq.vhdl

For one thing you need to add an “apps” section to your snapcraft.yaml:

apps:
  myapp:
    command: shell_command_to_run_within_the_snap
    plugs: [foo, bar]

I’m ccing the snapcraft developer @sergiusens for some hints on how to use snapcraft outside of Ubuntu.

i have a suspicion that snapcraft wants dpkg to install build environments (compiler and friends) as well as build-packages listed in snapcraft.yaml …

on solus you are probably better off to build inside a docker or lxd container for the moment …

1 Like

I think snapcraft has built-in support for using docker/lxd (not sure which) and you can probably use it this way.

i’m not sure any of our documentation mentions that though …
but yes …

@Justin try with:

snapcraft cleanbuild

that will kick off a container build …

1 Like

Alternatively @Justin try sudo snap install snapcraft --candidate to get snapcraft

Edit: wrong problem (though this will save you from building from source in the future), Ogra is right that snapcraft cleanbuild will allow you to build in an LXD container though which will solve your problem here. I did read somewhere that building in LXD will be default (i.e. will happen when you use snapcraft without cleanbuild) in a future snapcraft release!

Solus doesn’t currently have lxd in their repos. I asked @ikey last week about this, and I think it’s just not there due to lack of demand. Perhaps someone could follow the request a package page on the Solus website to get lxd in there?

Can snapcraft snap use LXD snap to build?

2 Likes

I think I read that using LXD for the snapcraft command is going to be default at some point so being able to use the LXD snap to build would be pretty important if that happened (so that to snap something all you need is snapd installed and then the snapcraft and lxd snaps (I guess snapcraft should automatically install the lxd snap if lxd is not detected, when snapcraft is run))

We have docker in Solus fwiw. As for LXD - as I said before, little demand. Perhaps making the LXD snap work so that people can snap install snapcraft is better. I don’t see any real need to package snapcraft itself.

In theory, but lxd snap appears broken on solus.

Is this a classic or “normal” snap? I’d be interested to see where liblxc.so.1 is meant to be. One assumes it
would be in the snap itself, right?

Any chance this is actually a classic snap using multiarch paths, so that the host can’t see them?

1 Like

IIRC it is a normal confined snap

OK so I’m able to run it OK on my host, using lxd init. However when I use snap run --shell lxd (and that is a completely useless debugging environment btw, no file, readelf, nm, default CWD, etc.) then the snapd libraries do not resolve. One assumes that more environment hacking is required by snapd itself for that, but:

bash-4.3$ LD_DEBUG=libs ./lxd
     10176:	find library=liblxc.so.1 [0]; searching
     10176:	 search cache=/etc/ld.so.cache
     10176:	 search path=/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64:/lib/tls:/lib/x86_64:/lib:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64:/usr/lib		(system search path)
     10176:	  trying file=/lib/x86_64-linux-gnu/tls/x86_64/liblxc.so.1
     10176:	  trying file=/lib/x86_64-linux-gnu/tls/liblxc.so.1
     10176:	  trying file=/lib/x86_64-linux-gnu/x86_64/liblxc.so.1
     10176:	  trying file=/lib/x86_64-linux-gnu/liblxc.so.1
     10176:	  trying file=/usr/lib/x86_64-linux-gnu/tls/x86_64/liblxc.so.1
     10176:	  trying file=/usr/lib/x86_64-linux-gnu/tls/liblxc.so.1
     10176:	  trying file=/usr/lib/x86_64-linux-gnu/x86_64/liblxc.so.1
     10176:	  trying file=/usr/lib/x86_64-linux-gnu/liblxc.so.1
     10176:	  trying file=/lib/tls/x86_64/liblxc.so.1
     10176:	  trying file=/lib/tls/liblxc.so.1
     10176:	  trying file=/lib/x86_64/liblxc.so.1
     10176:	  trying file=/lib/liblxc.so.1
     10176:	  trying file=/usr/lib/tls/x86_64/liblxc.so.1
     10176:	  trying file=/usr/lib/tls/liblxc.so.1
     10176:	  trying file=/usr/lib/x86_64/liblxc.so.1
     10176:	  trying file=/usr/lib/liblxc.so.1
     10176:	
./lxd: error while loading shared libraries: liblxc.so.1: cannot open shared object file: No such file or directory

Anyway, I can’t seem to reproduce @popey’s issue host-side, and there isn’t an ideal way to actually force an environment for snapd execution, i.e. we kinda need LD_DEBUG working to test this properly.

The LXC snap is both normal and special. It is using strict confinement but it is also given enough permissions to manage containers and that allows it to free itself out of the sandbox. Apparently the way it is doing this assumes something about Ubuntu as should not fail to function.

CC: @stgraber

1 Like

Opened up a fresh VM:

sudo snap install snapcraft --candidate --classic

Then went to do an init and got:

justin@solus-vm ~/Builds/snap $ snapcraft init Traceback (most recent call last): File “/snap/snapcraft/349/bin/snapcraft”, line 11, in load_entry_point(‘snapcraft==2.33’, ‘console_scripts’, ‘snapcraft’)() File “/snap/snapcraft/349/usr/lib/python3.6/site-packages/pkg_resources/init.py”, line 565, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File “/snap/snapcraft/349/usr/lib/python3.6/site-packages/pkg_resources/init.py”, line 2631, in load_entry_point return ep.load() File “/snap/snapcraft/349/usr/lib/python3.6/site-packages/pkg_resources/init.py”, line 2291, in load return self.resolve() File “/snap/snapcraft/349/usr/lib/python3.6/site-packages/pkg_resources/init.py”, line 2297, in resolve module = import(self.module_name, fromlist=[‘name’], level=0) File “/snap/snapcraft/349/lib/python3.6/site-packages/snapcraft/init.py”, line 394, in from snapcraft._baseplugin import BasePlugin # noqa File “/snap/snapcraft/349/lib/python3.6/site-packages/snapcraft/_baseplugin.py”, line 21, in from snapcraft.internal import common File “/snap/snapcraft/349/lib/python3.6/site-packages/snapcraft/internal/init.py”, line 20, in from snapcraft.internal.project_loader import load_config # noqa File “/snap/snapcraft/349/lib/python3.6/site-packages/snapcraft/internal/project_loader.py”, line 28, in from snapcraft.internal import ( File “/snap/snapcraft/349/lib/python3.6/site-packages/snapcraft/internal/parts.py”, line 28, in from snapcraft.internal import ( File “/snap/snapcraft/349/lib/python3.6/site-packages/snapcraft/internal/pluginhandler/init.py”, line 32, in from snapcraft.internal import ( File “/snap/snapcraft/349/lib/python3.6/site-packages/snapcraft/internal/sources/init.py”, line 96, in from ._deb import Deb # noqa File “/snap/snapcraft/349/lib/python3.6/site-packages/snapcraft/internal/sources/_deb.py”, line 17, in import debian.debfile File “/snap/snapcraft/349/lib/python3.6/site-packages/debian/debfile.py”, line 26, in from debian.changelog import Changelog File “/snap/snapcraft/349/lib/python3.6/site-packages/debian/changelog.py”, line 37, in from debian import debian_support File “/snap/snapcraft/349/lib/python3.6/site-packages/debian/debian_support.py”, line 31, in apt_pkg.init() SystemError: W:Unable to read /etc/apt/apt.conf.d/ - DirectoryExists (2: No such file or directory), E:Unable to determine a suitable packaging system type justin@solus-vm ~/Builds/snap $

Yes it can. This is how we in the team use it.

Fresh VM with Ubuntu or Solus, from PS1 it seems to be solus. It won’t work yet on Solus until someone implements the packaging provider side of it, but furthermore, the base for solus would be needed.

The alternative is to go down the path of lxd or docker from solus.