Package Details: snapd 2.71-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: 227
Popularity: 2.41
First Submitted: 2018-01-07 17:37 (UTC)
Last Updated: 2025-08-19 14:45 (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

1 2 3 4 5 6 .. 26 Next › Last »

xuiqzy commented on 2025-07-21 10:50 (UTC)

@bboozzoo You can rename the file that is downloaded with the sth::https:://... syntax in the url variable, like in the firefoy-nightly and other packages where the upstream filename stays the same. See warning box here for more info: https://wiki.archlinux.org/title/PKGBUILD#source But one could also argue makepkg or the AUR helper should just delete and retry ideally if the checksum doesn't match.

bboozzoo commented on 2025-07-17 18:26 (UTC) (edited on 2025-07-17 18:55 (UTC) by bboozzoo)

@MissRin my guess is you managed to update snapd before the upstream replaced the tarball. Since the file name is identical, makepkg won't download the file again, so it takes the file you have in the source directory, attempts to verify the checksum and fails. Eh, what a mess. Let me see if I can provide a reasonable upgrade path.

MissRin commented on 2025-07-17 17:42 (UTC)

snapd-2.70.tar.xz is failing the validity check still attempting to upgrade from 2.70-1 to 2.70-2

<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.

1 2 3 4 5 6 .. 26 Next › Last »