Package Details: snapd 2.62-2

Git Clone URL: https://aur.archlinux.org/snapd.git (read-only, click to copy)
Package Base: snapd
Description: Service and tools for management of snap packages.
Upstream URL: https://github.com/snapcore/snapd
Licenses: GPL3
Conflicts: snap-confine
Submitter: Barthalion
Maintainer: bboozzoo (zyga, mardy)
Last Packager: bboozzoo
Votes: 210
Popularity: 2.59
First Submitted: 2018-01-07 17:37 (UTC)
Last Updated: 2024-04-29 06:41 (UTC)

Pinned Comments

bboozzoo commented on 2018-10-25 11:56 (UTC) (edited on 2024-04-09 07:39 (UTC) by bboozzoo)

Package update notes

2.36

2.36 is the first release with AppArmor enabled by default on Arch.

If you do not have AppArmor enabled at boot there should be no functional changes visible.

If you wish to use snaps with Apparmor, first make sure that Apparmor is enabled during boot, see https://wiki.archlinux.org/index.php/AppArmor for details. After upgrading the package, you need to do the following steps:

  • Reload the profiles: systemctl restart apparmor.service
  • Restart snapd: systemctl restart snapd.service
  • Load profiles for snaps: systemctl enable --now snapd.apparmor.service
2.62

Since 2.62 snapd generated additional files describing the sandbox. The snapd service needs to be restarted after the update for snaps to continue working (unless the system is rebooted after the update, in which case no additional steps are needed). To restart, run systemctl restart snapd.service

Latest Comments

« First ‹ Previous 1 .. 13 14 15 16 17 18 19 20 21 22 23 24 Next › Last »

bboozzoo commented on 2018-12-23 08:43 (UTC)

@C0rn3j squashfs driver is in the kernel already. I don't see why you'd need to use squashfuse on Arch unless you're on a custom kernel without squashfs, or upgraded the kernel but did not reboot (effectively anything that loads drivers on-demand will fail at this point), or running Arch in a container.

The first and the last case could use optdepends, but IMO a wiki note would be more useful (or both even).

The upgraded kernel case is unfortunately a lost cause, unless fuse was it was already loaded, squashfuse will fail too.

after running it twice because of irrelevant snapd bug

Can you describe the problem?

C0rn3j commented on 2018-12-23 02:38 (UTC)

I just setup a fresh privileged LXD container with Arch.

I then installed this package, but was getting a hard middle finger from snapd.

After installing squashfuse and fuse3, I could snap install something just fine(after running it twice because of irrelevant snapd bug). Those two packages (not 100% sure that squashfuse is needed) are not even in optdepends.

rvlobato commented on 2018-12-18 16:25 (UTC)

Indeed, @bboozzoo, you were right, thanks! Now everything works fine.

bboozzoo commented on 2018-12-18 07:37 (UTC)

@rvlobato libgo.so is used by gcc-go. My guess would be you've built snapd using gcc-go and then it was removed or replaced with go. If you still have the package file, you can extract the .BUILDINFO file and see what was installed at the time. The upstream test suite running on Arch builds snapd using go. I'd recommend you install go, rebuild the package and pacman -U the new one.

FWIW, snap-update-ns is built statically, but also requires CGO. Proper flags are passed, to make it work. Maybe the go frontend provided by gcc-go interprets/handles the flags differently.

rvlobato commented on 2018-12-17 22:32 (UTC)

Hello, I have installed according the Wiki, but I am having this issue for any app installed:

snap-update-ns: error while loading shared libraries: libgo.so.13: cannot open shared object file: No such file or directory snap-update-ns failed with code 127: No such file or directory

Looking around I din't find anything. I have this libgo.so.13 on /usr/lib/ and have tested with apparmor disable/enabled and checking dmesg, there is no sign of apparmor is blocking snap. I reinstalled the base and base-devel as well both the apparmor/snapd without success.

Version of snap: snap 2.36.2-1 snapd 2.36.2-1 series 16 arch - kernel 4.19.8-arch1-1-ARCH

bboozzoo commented on 2018-10-25 11:56 (UTC) (edited on 2024-04-09 07:39 (UTC) by bboozzoo)

Package update notes

2.36

2.36 is the first release with AppArmor enabled by default on Arch.

If you do not have AppArmor enabled at boot there should be no functional changes visible.

If you wish to use snaps with Apparmor, first make sure that Apparmor is enabled during boot, see https://wiki.archlinux.org/index.php/AppArmor for details. After upgrading the package, you need to do the following steps:

  • Reload the profiles: systemctl restart apparmor.service
  • Restart snapd: systemctl restart snapd.service
  • Load profiles for snaps: systemctl enable --now snapd.apparmor.service
2.62

Since 2.62 snapd generated additional files describing the sandbox. The snapd service needs to be restarted after the update for snaps to continue working (unless the system is rebooted after the update, in which case no additional steps are needed). To restart, run systemctl restart snapd.service

bboozzoo commented on 2018-10-11 20:37 (UTC)

@beidl Yes. It's already enabled in snapd-git. With a PR that landed today, the generated security policy is not downgraded on Arch anymore so the AppArmor profiles for snaps are not more fine grained. All this will be part of the upcoming 2.36 release. I'm plan to enable AppArmor by default in snapd with the next update in a week or so.

beidl commented on 2018-10-11 19:52 (UTC) (edited on 2018-10-11 19:52 (UTC) by beidl)

With AppArmor enabled in kernel packages provided in the default repos what are the chances of enabling AppArmor support in the snapd PKGBUILD by default?

bboozzoo commented on 2018-09-14 06:19 (UTC)

@eschwartz thanks for the tip. I ended up adding a hook locally. Your aurpublish project looks like a very nice alternative, I think I'll start using it and migrate to the repo layout it expects.

eschwartz commented on 2018-09-14 01:04 (UTC)

There have never been any such checks, and if there were it would prevent many legitimate update situations. Or lead to a world where the pkgrel gets updated every time whitespace or quoting gets fixed in a PKGBUILD...

I'd suggest instead, using something like community/aurpublish which provides githooks to keep .SRCINFO up to date.

« First ‹ Previous 1 .. 13 14 15 16 17 18 19 20 21 22 23 24 Next › Last »