Hello Snapcrafters! The Snapcraft team is delighted to announce that version 3.4 is now available.
These are the release notes.
The snapcraft snap for 3.4 currently available in the candidate channel, to try it out run:
$ sudo snap install --candidate --classic snapcraft
Of, if you already have it installed, to try it out run:
$ sudo snap refresh --candidate snapcraft
Feedback is more than welcome!
Ran a whole ton of snaps through 3.4 and didn’t see any 3.4 specific issues.
Tested snaps:
stage-snaps, core18, command-chain, adopt-info
This release has reached the stable channel
Is there any plan to support the lxd provider on arm64? When installing snapcraft on arm64, I can’t use multipass because our linux-raspi kernel doesn’t include the right kernel config to enable kvm support, so I’m trying to build with lxd and that doesn’t work because snapcraft can’t find the minimal cloud images for arm64, so I’m wondering if a fallback could be implemented for other architectures that uses the default ubuntu:18.04 images that work fine with lxd on arm64?
Example output:
ubuntu@ubuntu:~/project$ snapcraft --use-lxd
Using 'snap/snapcraft.yaml': Project assets will be searched for from the 'snap' directory.
The LXD provider is offered as a technology preview for early adopters.
The command line interface, container names or lifecycle handling may change in upcoming releases.
Launching a container.
An error occurred with the instance when trying to launch with 'LXD': The requested image couldn't be found.
Ensure that 'LXD' is setup correctly and try again.
ubuntu@ubuntu:~/project$ lxc launch ubuntu:16.04
Creating the container
Container name is: fluent-locust
Starting fluent-locust
ubuntu@ubuntu:~/project$ arch
aarch64
We will soonish-ly be aligned with the launchpad buildds and use similar images to what they use, but we will not fallback to using full fledged images, I guess at that point you are better creating a container and using --destructive-mode in that container.
So I assume that since launchpad buildd works with arm64, that also means that the lxd images (wherever they come from) will also have an arm64 variant. That’s good enough for me.
And also, yes in the meantime I just used destructive-mode in a manually created lxd container.
Is there an assessment when there will be support for armhf/arm64 ?.
Using the method with destructive-mode does not work for me.
I have encounter a bug in the snapcraft from apt and can’t continue working with it anymore.
Is your program open source / non-proprietary? If so you could try using snapcraft remote-build to build in our cloud. Docs are at https://snapcraft.io/docs/remote-build
Thank you, currently the code isn’t public.
Is there other workarounds that you can think of?
Did you manually create a lxd container of the appropriate snap base (i.e. if your snap is based on core18, then create an ubuntu:18.04 image) and then install snapcraft as a snap in the container and run with --destructive-mode ? What’s the issue with that method if that’s what you tried?
@ijohnson In the lxd container after the command sudo apt update && sudo apt install -y squashfuse
I still can’t sudo snap install snapcraft --classic same error as before:
error: system does not fully support snapd: cannot mount squashfs image using "fuse.squashfuse": fusermount: mount failed: Operation not permitted
I lunch the lxc shell wih sudo because I get Error: Get http://unix.socket/1.0: dial unix /var/snap/lxd/common/lxd/unix.socket: connect: permission denied
Can this effect the result as described here?
root@lenient-kodiak:~# uname -r
4.14.111@guyluz11: what OS are you running? which kernel package? Does the kernel config enable CONFIG_SQUASHFS & CONFIG_SQUASHFS_XZ?
@cjp256
OS: friendly core (nanopi-duo2_sd_friendlycore-xenial_4.14_armh based on Ubuntu core)
Kernel package: 4.14.111
Does the kernel config enable CONFIG_SQUASHFS & CONFIG_SQUASHFS_XZ: how to check ?
I can run snaps on it, just cant run the snapcraft from the snap (snapcraft can be run when installed from apt).
Unfortunately friendly core isn’t supported, it is not actually based on Ubuntu Core. See @ogra’s comment here and elsewhere on the forum: How can I run ubuntu-core 18 on allwinner A64?
I don’t recall the details but I don’t think that they have all the same kernel configs set as a normal Ubuntu kernel does.
Just updating that I contacted the company for help.
In the meantime I am building the snap on my laptop with the last snapcraft version and using architectures: [all] and than transferring it to the nanopi-duo2.
Thank you all for the support.
After some learning of the linux kernel config I add all the configs from here to my image except CONFIG_SECURITY which give me error,
including CONFIG_KVM=y and CONFIG_DEFAULT_SECURITY_APPARMOR=y and CONFIG_SECURITY_APPARMOR=y wich you said are importent for snapcraft.
Now I am getting new error when using sudo multipass launch snapcraft:core18 -vvv
launch failed: cannot connect to the multipass socket Please ensure multipassd is running and '/var/snap/multipass/common/multipass_socket' is accessible
Same for sudo snapcraft
Am I missing any more configs?
So just to remind myself after the holiday break, you have a armhf board, and you are trying to build snaps on it that have base: core18, and:
1 You aren’t able to use lxd because inside the lxd container you can’t install snaps
2 You aren’t able to use multipass because you weren’t able to get the right config options to enable KVM
Is that accurate? I think that the second option should really be discussed more over at Config requirements and possibly an issue about the kernel config requirements that multipass has (perhaps a new issue at github.com/CanonicalLtd/multipass/issues is warranted to clarify this)
The first option still seems like the path of least resistance for you, when you try to install a snap inside the lxd container, do you see any denials or other suspicious messages in your system log either inside the container or on the host?
I have add CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1 and removed CONFIG_SECURITY=y from the config file and now I can build with snapcraft --destructive-mode without lxd.
lxd init now return errors installing so my question is, is it ok to run snapcraft --destructive-mode outside of lxd or is it a bad practice
By the why the device System load is high with the new configs and it disconnect all the time from the internet and restart is needed so not ideal.
I’m afraid we can’t help with this issue without more details, however this conversation has gotten a bit off-topic from the call for testing of a version of snapcraft from 9 months ago, so if you would like to continue I’d suggest starting a new topic.
Building with destructive-mode outside of an ephemeral environment isn’t necessarily bad practice, but note that if you aren’t building off of the same base as the snap you’re building, snapcraft will pull in potentially incorrect or incompatible libraries and could make your snap not work.