Package Details: snapd 2.62-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, mardy)
Last Packager: bboozzoo
Votes: 209
Popularity: 1.97
First Submitted: 2018-01-07 17:37 (UTC)
Last Updated: 2024-04-09 07:35 (UTC)

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:

  • 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

Latest Comments

« First ‹ Previous 1 .. 17 18 19 20 21 22 23 24 Next › Last »

aimileus commented on 2018-03-23 16:37 (UTC)

@cmsigler, you are right that these files should be removed. Upstream includes a script to clean up the snapd files, but this does not include the udev rules. Since these rules are generated on the fly (one per snap), it is also not possible to include them in the package. For now I just decided to remove them manually in snapd.install.

cmsigler commented on 2018-03-21 15:47 (UTC)

Hi,

I hope these aren't stupid questions.

A few days ago I installed snapd from AUR and tried it. The snaps I installed didn't work and that's fine, no complaint as it was purely an experiment. I removed snapd. This left behind one file I found today -- `/etc/udev/rules.d/70-snap.core.rules'. This is some kind of USB modem manager file(?). Please see:

https://github.com/snapcore/snapd/blob/master/interfaces/builtin/modem_manager.go

1.) The package itself seems to generate this file? Does that mean it's not intended to go in /usr/lib/udev/rules.d/ ? Or should it? 2.) Is it possible to have the package manager clean up this file upon removal?

Just something I noticed. The answer to both may be "no." :) HTH and thank you.

Clemmitt Sigler

bboozzoo commented on 2018-03-12 06:31 (UTC)

@archlinux38 Can you post that to https://forum.snapcraft.io so that we don't spam the comments here?

The only think I can suggest now, having a cloned tree and while in the package directory:

  • go env and paste the output somewhere
  • export GOPATH=$PWD
  • try to build one of the components, eg. go build -x -v -o test-snapd github.com/snapcore/snapd/cmd/snapd once it fails, upload the log somewhere

archlinux38 commented on 2018-03-11 20:15 (UTC)

@aimileus I wish I could answer that but I can't. I don't think I have changed anything like that. Can you guide me how to look for those changes?

aimileus commented on 2018-03-10 15:50 (UTC)

@archlinux38, do you have a dirty go environment that might complicate things, e.g. a GOPATH/GOROOT environment variable set? Could you try building in a clean chroot, running extra-x86_64-build instead of makepkg?

archlinux38 commented on 2018-03-03 11:05 (UTC)

I have tried to build snapd for a couple of months in hope that it would somehow work some day but this is what I get every time I try:

Installing govendor

net

cannot load DWARF output from $WORK/b105//cgo.o: decoding dwarf section info at offset 0x0: too short ==> ERROR: A failure occurred in build(). Aborting...

anthraxx commented on 2018-03-01 11:56 (UTC)

@aimileus: thanks a lot, very much appreciated, more arch-ish now :D PS: i love your commit messages, thats how all AUR/repo message should be, explaining the why and whats. big thumbs!

aimileus commented on 2018-02-24 10:42 (UTC)

@anthraxx, I removed the /snap symlink and systemd unit handling. If a user wants to install classic snaps the Arch Wiki and the snap command instruct the user to create a symlink manually.

anthraxx commented on 2018-02-22 18:45 (UTC) (edited on 2018-02-22 19:59 (UTC) by anthraxx)

why was the symlink to /snap reintroduced that violaes the FHS strongly and populates / with a rediculous directory? It has been changed for a reason and just because of --classic its still a bad idea to add. Please drop it again.

PS: install scripts doing systemd start/stop/reload things are not what one would call "the arch way"

bboozzoo commented on 2018-02-12 09:43 (UTC)

@precrisk interesting thought. I'm afraid we're missing a larger bunch of dependencies, snapd-glib and snapd-qt to start with. Off the top of my head, there's also snap backend for gnome-software. You would end up rebuilding 2-3 packages at least. No promises at this point, but I can try a look into at least packaging the pluggable backends.

OTOH it'd be much easier if snapd was in 'community'.

« First ‹ Previous 1 .. 17 18 19 20 21 22 23 24 Next › Last »