| 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: | 222 |
| Popularity: | 4.79 |
| First Submitted: | 2018-01-07 17:37 (UTC) |
| Last Updated: | 2025-01-24 11:51 (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.
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.
@HD_hirku pkg/ in the package directory is created by makepkg. I'm sorry but there's nothing I can fix here for you.
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
@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.
@selfdenial the delay is there for a reason. The candidate release gets to run not only on a number of distros, but also on actual hardware devices and test deployments (eg. Ubuntu Core). This depends on the capacity of the lab which is in charge of the testing. Upstream proceeds with the release only if no regressions have been found.
@bitten There is not yet a 2.67 release, only a tag. The Canonical trend seems to include a waiting period (up to a month) between the addition of the tag and an actual release. Note that go.mod isn't yet synchronized with vendor. Here is a working diff to build 2.67 for those willing to test it experimentally:
diff --git a/PKGBUILD b/PKGBUILD
index bf5ef03..7be88bd 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -8,7 +8,7 @@ pkgdesc="Service and tools for management of snap packages."
depends=('squashfs-tools' 'libseccomp' 'libsystemd' 'apparmor')
optdepends=('bash-completion: bash completion support'
'xdg-desktop-portal: desktop integration')
-pkgver=2.66.1
+pkgver=2.67
pkgrel=1
arch=('x86_64' 'i686' 'armv7h' 'aarch64')
url="https://github.com/snapcore/snapd"
@@ -18,9 +18,9 @@ conflicts=('snap-confine')
options=('!strip' 'emptydirs' '!lto')
install=snapd.install
source=(
- "$pkgname-$pkgver.tar.xz::https://github.com/snapcore/${pkgname}/releases/download/${pkgver}/${pkgname}_${pkgver}.vendor.tar.xz"
+ "$pkgname-$pkgver.tar.xz::https://github.com/canonical/${pkgname}/archive/refs/tags/${pkgver}.tar.gz"
)
-sha256sums=('5fa662062562443b2a005ed1aad359d6cc0c74ffbb555af701a4c1f510896b7b')
+sha256sums=('9c646294b8afb347bc5bb7b4621ac8c7d86aad57b7198ada0282b783c34219f2')
prepare() {
@@ -47,6 +47,9 @@ build() {
export CGO_CXXFLAGS="${CXXFLAGS}"
export CGO_LDFLAGS="${LDFLAGS}"
+ # Sync go.mod with vendor (useful for unreleased tags)
+ go mod vendor
+
# Generate snapd.defines.mk, this file is included by snapd.mk.
cat >"$srcdir/snapd.defines.mk" <<__DEFINES__
# This file is generated by snapd packaging
@username227 not sure why you see that, make has supported -j without any argument for years now, just see https://man.archlinux.org/man/make.1. Besides it can only come from MAKEFLAGS, which are set in makepkg.conf in your system.
What about this error?
make: the '-j' option requires a positive integer argument
==> ERROR: A failure occurred in build(). Aborting...
Opened a PR for the upstream repository at https://github.com/snapcore/snapd/pull/13959 I'll cherry pick the patch and will push a package update.
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:
systemctl restart apparmor.servicesnapd:systemctl restart snapd.servicesystemctl enable --now snapd.apparmor.service2.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