Package Details: snapd 2.42.2-1

Git Clone URL: https://aur.archlinux.org/snapd.git (read-only)
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: 100
Popularity: 3.48
First Submitted: 2018-01-07 17:37
Last Updated: 2019-11-25 10:30

Pinned Comments

bboozzoo commented on 2018-10-25 11:56

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

Latest Comments

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

aimileus commented on 2018-06-24 06:04

@rplanchuelo, autoconf is part of the base-devel group. Packages in base-devel are assumed to be installed when building (AUR) packages, and should not be included as build dependencies.

https://wiki.archlinux.org/index.php/Arch_User_Repository#Prerequisites

rplanchuelo commented on 2018-06-23 05:20

I have problems with the last update:

/home/rober/.cache/aurman/snapd/PKGBUILD: línea 74: autoreconf: no se encontró la orden ==> ERROR: Se produjo un fallo en build(). Cancelando... 2018-06-23 07:19:24,818 - wrappers - makepkg - ERROR - makepkg query makepkg -cf --noconfirm failed

I'VE JUST FOUND THE SOLUTION: You have to install "autoconf" in orther to execute "autoreconf" (line 74). Maybe autoconf should be a dependencia.

bboozzoo commented on 2018-06-15 05:57

@ibrokemypie your current LDFLAGS setting appears to be incorrect. ld will be called like this: /usr/bin/ld .. -01 --sort-common --as-needed -z relro now, notice that now is passed without a preceding -z, making ld interpret it as an object file.

Can you edit your LDFLAGS to be: LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" and build again?

ibrokemypie commented on 2018-06-15 04:49

@bboozzoo My makepkg.conf is here: https://hastebin.com/bozoduwete.coffeescript

joopdo commented on 2018-06-13 05:46

@bboozzoo that's it! Thanks a lot for the quick response and fix for my problem. Cheers

bboozzoo commented on 2018-06-12 14:06

@joopdo pushed a change to use the source tarball with vendor dependencies bundled in. Can you check if it works for you now?

joopdo commented on 2018-06-12 08:23

@bboozzoo I assumed it's generic due to the unrecognized import path.

If specific, I look myself. I'm based in China (forgot to mention this fact) but got same response with and without VPN. I noticed that my first mention included some output from my proxy, sorry for any confusion.

bboozzoo commented on 2018-06-12 07:50

@joopdo do the hosts you build the package on have network access or are behind some proxy that may mangle the headers?

I can probably look into using the source tarball that includes the vendored dependencies. The downside is that sometimes it took a while to have it published on github releases page.

joopdo commented on 2018-06-12 06:38

Current AUR seems to fail for me on multiple machines.

Govendor reports: Obtaining dependencies Error: Remotes failed for: Failed for "golang.org/x/crypto/cast5" (failed to ping remote repo): unrecognized import path "golang.org/x/crypto/cast5"

bboozzoo commented on 2018-06-12 06:07

@ibrokemypie can you share your makepkg.conf and how you build the package? I tried building it with clang (and lld) inside and outside of a clean chroot, but failed to reproduce the build issue you're seeing. Can you double check that binutils is properly installed?