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': []}.
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?
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.
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:
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.
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 $
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.