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?
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.
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?
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
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.
Hello,
I am on Solus, and even with SNAPCRAFT_CONTAINER_BUILDS=1, the init fails with the same error as @Justin.
PS: I had a hard time finding this snap : snap find snapcraft does not returns it in the results (same on the website).
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?’
Bookmarked .
Have you received any reply from Solus?
you can easily do what init does manually to work around this …
SNAPCRAFT_CONTAINER_BUILDS=1 will only affect the build like cleanbuild will (not init) … when you do snapcraft init all that happens is that a ./snap directory gets created and a boilerplate snapcraft.yaml gets put in place:
ogra@anubis:~/dump$ snapcraft init
Created snap/snapcraft.yaml.
Edit the file to your liking or run `snapcraft` to get started
ogra@anubis:~/dump$ cat snap/snapcraft.yaml
name: my-snap-name # you probably want to 'snapcraft register <name>'
version: '0.1' # just for humans, typically '1.2+git' or '1.3.2'
summary: Single-line elevator pitch for your amazing snap # 79 char long summary
description: |
This is my-snap's description. You have a paragraph or two to tell the
most important story about your snap. Keep it under 100 words though,
we live in tweetspace and your description wants to look good in the snap
store.
grade: devel # must be 'stable' to release into candidate/stable channels
confinement: devmode # use 'strict' once you have the right plugs and slots
parts:
my-part:
# See 'snapcraft plugins'
plugin: nilApologies, I didn’t realize the container commands didn’t affect anything other than build, thanks! 
@Ads20000 thanks for the answer. I just did a copy/paste of the command I found above on this post without paying really attention to the --candidate so indeed it logical to not see it in the search results.
@ogra thanks, I created the snapcraft.yml file in the existing snap directory but it doesn’t really help; actually all the snapcraft commands fails with that message. I saw a bug was created some time ago on launchpad so I guess all I can do for now is waiting or use an ubuntu virtual machine.
@Bettys as I understand, there is no intention atm to add native LXD and snapcraft packages in the Solus repository. The idea would be either to use: the snapcraft and the LXD snaps or the snapcraft snap only with the SNAPCRAFT_CONTAINER_BUILDS=1 environment variable.
The problem is that currently none of these 2 snaps work on Solus.
Thanks for the help & feedback anyway ! 