name: my-snap-name # you probably want to 'snapcraft register <name>'
base: core18 # the base snap is the execution environment for this snap
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: dump
source: yolo
Then I would expect to run the command snapcraft in the root of these two directories and get a snap file my-snap-name_0.1_amd64.snap which I can then proceed to inspect with unsquashfs -l *.snap and I should see the file test.txt somewhere in it.
Or at least if I ran multipass shell <container name> I should find these files somewhere in it maybe…
Should I not? What do I not understand?
Why I ask this question: I want to debug a snap not working because some files are missing. My current assessment: Of course they are missing, dump doesn’t do anything…
Dump should be working pretty much as you described. It takes the source and it ends up in $SNAPCRAFT_PRIME unmodified. You’d expect to see test.txt in the root directory of the .snap file
when it’s mounted/unsquashed.
I’m curious if the behaviour might change if you have:
parts:
my-part:
# See 'snapcraft plugins'
plugin: dump
source: ./yolo
source-type: local
The use of snapcraft clean might be helpful to reset the build environment too.
Hi James, I did as you suggested, but to no avail. Here’s a copy of my terminal screen in front of me (with username and hostname deleted):
~/snap-test$ tree
.
├── my-snap-name_0.1_amd64.snap
├── snap
│ └── snapcraft.yaml
└── yolo
└── test.txt
2 directories, 3 files
~/snap-test$ cat snap/snapcraft.yaml
name: my-snap-name # you probably want to 'snapcraft register <name>'
base: core18 # the base snap is the execution environment for this snap
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: dump
source: ./yolo
source-type: local
~/snap-test$ unsquashfs -l *.snap
Parallel unsquashfs: Using 8 processors
1 inodes (1 blocks) to write
squashfs-root
squashfs-root/meta
squashfs-root/meta/snap.yaml
~/snap-test$
There’s still no file… is my version broken?
~/snap-test$ snapcraft --version
snapcraft, version 5.0
I’d assume your snapcraft isn’t broken, snaps are designed to be robust to corruption afterall!
I don’t see anything obviously defective with your snapcraft.yaml, so I’d probably propose 2 other possible workarounds that might help identify the problem.
Firstly you could try simply changing the base: core18 to base: core20. This uses different plugins that might change the behaviour. (It’s still called dump, but the process works slightly differently).
Secondly you can try using the LXD backend for building rather than the Multipass backend. Which would look like
Other building commands would also need the --use-lxd parameter, e.g, snapcraft clean --use-lxd
And of course, feel free to try both core20 + LXD in tandem.
While this is just throwing darts blindly and seeing what hits, hopefully they’re both easy enough to try on the off chance they fix the problem instantly.
Switching to core20 had no effect on the result, however --use-lxd had! I now see:
$ unsquashfs -l *.snap
Parallel unsquashfs: Using 8 processors
2 inodes (2 blocks) to write
squashfs-root
squashfs-root/meta
squashfs-root/meta/snap.yaml
squashfs-root/test.txt
This is great, it’s evening here so I will stop for now, but tomorrow I’ll check if I need source-type and the ./ in front of the folder name.
Oh by the way, I had to write
sudo snapcraft --use-lxd
… it would not work without sudo:
$ snapcraft --use-lxd
An error occurred when trying to communicate with the 'LXD' provider: cannot connect to the LXD socket ('/var/snap/lxd/common/lxd/unix.socket')..
Thank you very much for the quick and good help.
I’m curious though, why multipass is not working. Perhaps a re-install would help…
If LXD isn’t working without sudo, I think sudo usermod -a -G lxd ${USER} and a reboot should fix it. It’s usually not recommended to run snapcraft with root access. On the Ubuntu systems I’ve used I’ve never had to actually set up the group permissions manually but I guess you never specified you’re even on Ubuntu
I couldn’t answer why it’s exclusively the Multipass backend that’s problematic here but hopefully someone more knowledgable would be able to chime in now. I think there’s a slight bias that the LXD backend is used more since it’s capable of being used in places where virtualisation for Multipass might not be available, so maybe this is something that’s just slipped through the cracks. LXD is even up for consideration about being made default for Core22 snaps on Ubuntu in the future.
I also want to add that instead of running snapcraft --use-lxd it’s possible to define an environment variable SNAPCRAFT_BUILD_ENVIRONMENT=lxd and then just use snapcraft.
I am mentioning this because my actual use-case is using the snap feature of electron-builder and when using the env var no further changes are required. (Just leaving this here in case someone googles for snapcraft with electron specifically.)
