Package Details: snapd 2.75.2-1

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)
Last Packager: bboozzoo
Votes: 231
Popularity: 3.35
First Submitted: 2018-01-07 17:37 (UTC)
Last Updated: 2026-04-20 08:01 (UTC)

Pinned Comments

bboozzoo commented on 2018-10-25 11:56 (UTC) (edited on 2025-07-10 11:42 (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

2.70

Snapd 2.70 drops setuid permissions on /usr/lib/snapd/snap-confine in favor of explicit file capabilities. After an upgrade to 2.70, the users are prompted to restart the apparmor.service otherwise attempts to run snaps will error with cannot set capabilities message.

Latest Comments

« First ‹ Previous 1 .. 7 8 9 10 11 12 13 14 15 16 17 .. 28 Next › Last »

bboozzoo commented on 2021-04-26 07:12 (UTC)

@sighup_mae yes it is maintained. I did not see a reason to update as the changes in point releases were focused on Ubuntu Core. The 2.50 release brings some changes to the desktop, hence the package will be updated again. If you are eager to see an update each time the upstream creates a new tag, you are always welcome to send me a patch.

sighup_mae commented on 2021-04-26 07:06 (UTC)

Are the maintainers still active? Package has been out-of-date for over a month now.

bendavis78 commented on 2021-03-24 16:08 (UTC) (edited on 2021-03-24 16:10 (UTC) by bendavis78)

I'm getting this error when running makepkg -i:

==> Starting check()...
snap-exec is not a static binary

yxgi5 commented on 2021-03-16 08:53 (UTC) (edited on 2021-03-16 09:03 (UTC) by yxgi5)

Is there any solution?


make[1]: Leaving directory '/home/andy/.cache/yay/snapd/src/snapd-2.49.1/cmd'
==> Starting check()...
snap-exec is not a static binary
error making: snapd

ArchRob commented on 2021-02-27 22:36 (UTC)

@benalexau the tip about pkgconf helped. I was getting weird errors like:

Traceback (most recent call last):
  File "/usr/bin/rst2man", line 26, in <module>
    publish_cmdline(writer=manpage.Writer(), description=description)
  File "/usr/lib/python3.9/site-packages/docutils/core.py", line 352, in publish_cmdline
    pub.set_components(reader_name, parser_name, writer_name)
  File "/usr/lib/python3.9/site-packages/docutils/core.py", line 94, in set_component

I ran sudo pacman -S pkgconf. It was already installed, and pacman confirmed it was simply reinstalling. But after that, I was able to build this package without issue. No idea why, but it worked.

bboozzoo commented on 2021-02-27 18:42 (UTC)

@rageltman looks like the Go compiler crashed in your system. Maybe try buliding a minimal hello world, you can find an example here: https://gobyexample.com/hello-world Perhaps you should also file a bug for the golang package.

rageltman commented on 2021-02-27 15:57 (UTC)

Not quite sure what to make of this one:

[2021-02-27T05:38:01.052Z] ==> Starting build()...
[2021-02-27T05:38:01.052Z] fatal: not a git repository (or any of the parent directories): .git
[2021-02-27T05:38:01.052Z] fatal: not a git repository (or any of the parent directories): .git
[2021-02-27T05:38:01.052Z] *** Setting version to '2.49-1' from user.
[2021-02-27T05:38:01.052Z] # net
[2021-02-27T05:38:01.052Z] cgo: cannot load DWARF output from $WORK/b058//_cgo_.o: decoding dwarf section info at offset 0x0: too short
[2021-02-27T05:38:01.052Z] # os/user
[2021-02-27T05:38:01.052Z] cgo: cannot load DWARF output from $WORK/b064//_cgo_.o: decoding dwarf section info at offset 0x0: too short
[2021-02-27T05:38:01.052Z] ==> ERROR: A failure occurred in build().
[2021-02-27T05:38:01.052Z]     Aborting...
script returned exit code 255

cindrmon commented on 2021-02-14 10:49 (UTC)

@bboozzoo thanks for the tip! it worked when i switched back to bash. i guess it is because i was using fish, no wonder it wouldn't work. thanks again!

bboozzoo commented on 2021-02-14 09:42 (UTC)

@cindrmon /etc/profile.d/snapd.sh is only sourced by bash and zsh. There's a systemd mechanism that injects the right variables into your session via /usr/lib/environment.d/990-snapd.conf which should also work if you use other shells. It's possible that your desktop environment can mess something up too, IIRC lxde did that. Lastly, the profile scripts in your $HOME can override PATH by mistake. I suggest you add a new account, log into that and check whether PATH includes snap locations.