The front page of snapcraft.io shows gentoo as a candidate for installing snaps.
Our installation guide points to a repo owned by @zyga which appears to be outdated. It delivers ancient snapd 2.15.
There have been a couple of issues filed to get this repo updated.
What’s the plan here? Are we planning to fully support gentoo?
If not, we should a) remove it from snapcraft.io and b) remove the install docs too?
Good point, we need to review this. Do we have anyone from Gentoo around here that would be interested in pushing this forward? That would be the best path forward, as it means someone that will always be living and knowing whether the package works or not.
I’ll also do a call out on Twitter to see if anyone close by is using it those days.
I’m not actually from Gentoo. I use Sabayon which is similar to Gentoo in a fair number of respects. anywho I plan on adding updated snap ebuilds to my overlay in a few days once I get things straightened out.
edit: I have posted the version bumped ebuild for snap-confine at https://github.com/JamesB192/JamesB192-overlay.git . I also have a version bumped ebuild for snapd but I should get it to install more than three files
Thank you for putting that together @jamesb192
What is the overall experience with snaps on Sabayon? Do you plan to move your overlay to the default archive in the future?
Not good. I never actually got it running. I would not be opposed to someone moving it upstream when I get it running. It is not like I am a Sabayon or Gentoo staff member.
edit: got it running just needed to build sys-libs/libseccomp with static-libs.
I just tried your package on Gentoo. I have an amd64 system running unstable.
I updated world within the past week.
Ran into a build error during autoconfigure of the snapd.
configure: error: xfs/xqm.h unavailable
Do you know what package provides these headers> I thought quota.
I did an emerge of quota, but still don’t have those files.
That particular file is in sys-fs/xfsprogs . I also chatted w/ @zyga on IRC the other day, and he advised me to among other thing remove some Ubuntu core specific files.
I added sys-fs/xfsprogs and sys-apps/apparmor to the depends of the ebuild.
The snapd ebuild now compiles and installs.
It does not work yet.
I am on a systemd (as opposed to openrc) system. That seems to be the type of system
initialization that is targeted by this ebuild, but the systemd service files are looking for snapd and other executables in the wrong places.
For instance, snapd was installed at /usr/bin/snapd, but the systemd service file looks for it at
/usr/lib/snapd/snapd
I should be able to look at this some more in a day or two.
I addressed that. Often, I am late getting things pushed. pull the repository again and the 2.30-r3 and 9999 (live) ebuilds should work. I deliberately did not keyword the live build.
Took a look at the ebuild today things for a while today.
First thing was it would not complete the ebuild process. The sandbox install was not working because it expected to find the file snap-confine.1.
That is the man page for snap-confine.
Tracked down that I did not have rst2man installed on my system.
With that not present, the man pages were not being created.
I assume that man pages are wanted – in which case dev-python/docutils needs to be
added as a dependency. I suppose the other alternative would be to massage the ebuild such that the man pages are not required. There would be several missing man pages besides just
the snap-confine.1
After that dependency was added, everything compiles and install.
systemctl start snapd
successfully completes.
But it fails to install and run the hello-world snap.
systemctl status snap-core-3887.mount
● snap-core-3887.mount - Mount unit for core
Loaded: loaded (/etc/systemd/system/snap-core-3887.mount; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Tue 2018-01-30 21:39:27 MST; 13s ago
Where: /snap/core/3887
What: /var/lib/snapd/snaps/core_3887.snap
Process: 6362 ExecMount=/bin/mount /var/lib/snapd/snaps/core_3887.snap /snap/core/3887 -t squashfs -o nodev,ro,x-gdu.hide (code=exited, st>
Jan 30 21:39:27 USWAI-PC-01185 systemd[1]: Mounting Mount unit for core…
Jan 30 21:39:27 USWAI-PC-01185 systemd[1]: snap-core-3887.mount: Mount process exited, code=exited status=32
Jan 30 21:39:27 USWAI-PC-01185 systemd[1]: snap-core-3887.mount: Failed with result ‘exit-code’.
Jan 30 21:39:27 USWAI-PC-01185 systemd[1]: Failed to mount Mount unit for core.
I’ve not dug into that yet. Anybody recognize what might be the problem?
Have you tried mounting the snap by hand? (it looks like squashfs or xz support might be missing in your kernel)
I posted a possibly broken bump to 2.34. Included in the revised ebuilds are checks for the kernel config options mentioned by someone (probably mborzecki @ this thread) I also updated the build from git version to be equivalent to the 2.34 ebuild. this is mostly in response to this thread.
Thank you for pushing this forward. I’m too tired to discuss this at length today but I will comment some more tomorrow.