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.42
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 2 3 4 5 6 7 8 .. 28 Next › Last »

<deleted-account> commented on 2025-07-17 09:54 (UTC)

Thanks for support ^^

zyga commented on 2025-07-17 09:21 (UTC)

I've updated 2.70 to -2 with changed sha256sum of the upstream tarball. Upstream release was re-generated with new changelogs, overwriting old tarballs.

<deleted-account> commented on 2025-07-17 07:51 (UTC)

Please fix sha256sums=('208c4356e17e96f25f8e5d4cc9c5494157099d15c091a530bb4f260aae9cf88b') to sha256sums=('4092c7e02d9d03c4c3c0546a0cddcff288ffffe484cd872f7df7565ab1428dbf')

gandalf239 commented on 2025-07-16 17:36 (UTC)

snapd-2.70.tar.xz when git cloned to my system fails integrity checks subsequent to executing makepkg -si

claymorwan commented on 2025-05-13 11:21 (UTC) (edited on 2025-05-13 11:22 (UTC) by claymorwan)

Can't install 2.68-1, getting this error when compiling:

/usr/bin/rst2man snap-confine/snap-confine.rst > snap-confine/snap-confine.8
Traceback (most recent call last):
  File "/usr/bin/rst2man", line 8, in <module>
    sys.exit(rst2man())
             ~~~~~~~^^
  File "/usr/lib/python3.13/site-packages/docutils/core.py", line 760, in rst2man
    rst2something('manpage', 'Unix manual (troff)', 'user/manpage.html')
    ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/docutils/core.py", line 739, in rst2something
    locale.setlocale(locale.LC_ALL, '')
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/locale.py", line 615, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting
make[1]: *** [Makefile:4465: snap-confine/snap-confine.8] Error 1
make[1]: Leaving directory '/home/claymorwan/.cache/paru/clone/snapd/src/snapd-2.68.4/cmd'
make: *** [Makefile:1365: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
error: failed to build 'snapd-2.68.4-1':
error: packages failed to build: snapd-2.68.4-1

bboozzoo commented on 2025-01-23 07:34 (UTC)

I've opened a PR to upstream splitting some make targets which should address this.

Though TBH, IDK how many times this needs to be stressed. Use a clean chroot to build the package. This is how repo packages are build. This is how AUR publishers should test build their packages. Use https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot as reference.

HD_hirku commented on 2025-01-23 03:09 (UTC)

Well, you can do several things actually:

# dmesg | grep DENIED | grep -E "(snapd.run-from-snap|snapd.core-fixup.sh)"
... apparmor="DENIED" operation="open" class="file" profile="snap.shellcheck.shellcheck" name="/home/build/snapd/src/snapd-2.67/data/systemd/snapd.run-from-snap" pid=12345 comm="shellcheck" requested_mask="r" denied_mask="r" fsuid=1234 ouid=1234
... apparmor="DENIED" operation="open" class="file" profile="snap.shellcheck.shellcheck" name="/home/build/snapd/src/snapd-2.67/data/systemd/snapd.core-fixup.sh" pid=12345 comm="shellcheck" requested_mask="r" denied_mask="r" fsuid=1234 ouid=1234

The problem is not related to makepkg but rather that the snapd build attempts to use a locally installed shellcheck which I had previously installed via snap. In other words, snap remove --purge shellcheck and then re-building this package will resolve the problem.

So it's either an upstream issue or possibly something you can patch here. Why upstream would attempt to run shellcheck during a local package build instead of through a separate CI/CD pipeline is... whatever.

bboozzoo commented on 2025-01-22 06:35 (UTC)

@HD_hirku pkg/ in the package directory is created by makepkg. I'm sorry but there's nothing I can fix here for you.

HD_hirku commented on 2025-01-22 04:11 (UTC)

When building this package, 2.67-1 282406315f8ec6a377263688b2bc73d7fe414530

if command -v shellcheck >/dev/null; then shellcheck snapd.run-from-snap snapd.core-fixup.sh; fi
snapd.run-from-snap: snapd.run-from-snap: openBinaryFile: permission denied (Permission denied)
snapd.core-fixup.sh: snapd.core-fixup.sh: openBinaryFile: permission denied (Permission denied)
make[1]: *** [Makefile:34: check] Error 2
make[1]: Leaving directory '/home/build/snapd/src/snapd-2.67/data/systemd'
make: *** [Makefile:2: all] Error 2
make: Leaving directory '/home/build/snapd/src/snapd-2.67/data'

Also of note, the created pkg/ directory has permissions of d--x--x--x

<deleted-account> commented on 2024-12-05 22:13 (UTC)

@bboozzoo I agree! Perhaps my prior comment didn't make that clear. My comments are in response to the premature out-of-date flagging of this package.

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 28 Next › Last »