After we released 2.27 it is time for a new snapd release! We branched the release/2.28 branch and the first 2.28~rc1 is already in the beta channel! Note that there is a bug in the script that generates the version numbers so “snap info core” will just show “2.28” for beta, we will fix this shortly.
More details and the timeline can be found here: The snapd roadmap
Please let us know if you have any specific issues or questions about the 2.28 releases.
Heh but then the 2.27 point release has bumped this off (and edge uses an older revision than beta)!
stable: 16-2.27.5 (2774) 85MB -
candidate: 16-2.27.5 (2774) 85MB -
beta: 16-2.27.6 (2844) 85MB -
edge: 16-2.27.5+git359.b67443d (2839) 87MB -
If only it were possible to use tracks for core but then to force upgrade between releases when they come out… (I don’t think it would be possible because having a forced upgrade between tracks defeats the point of tracks?)
what makes you think that ? edge uses 2.27.5 plus master up to git commit b67443d … so this is definitely newer …
ERR … oops … i missed the .5 … this is simply due to the fact that edge has not had its daily build yet (simply timing) … unlike stable/beta/candidate which require manual builds, QA runs and the like, the edge builds are driven by a schedule.
Yeah fair! I can’t seem to find that commit though, as it happens, maybe I’m searching GitHub wrong…
probably @mvo can help with this (i had problems finding it in GH or in a local branch as well in the past) and document how to actually find the right commit when doing a search based on the release version …
Indeed, yesterday 2.28~rc1 was not available because we did another point release for 2.27. However this is fixed now and 2.28~rc2 is now in the beta channel (and edge builds are building from master as usual even though the version number is slightly confusing).
snapd 2.28 does not build on Fedora, thanks to snapcore/snapd#3733.
I’m extremely annoyed that vendored tarballs have been passed to the Fedora CI this entire time, because it means that the build dependencies aren’t getting properly updated when people add new code. Consequently, the CI has been providing me no value and adding more work.
Hopefully, this will be fixed in master with snapcore/snapd#3859, but this PR must land for 2.28 as well, because the CI builds have been wrong this entire time, and they haven’t been properly testing the builds.
Thanks for finding this issue! There is a 2.28 PR for #3859 (https://github.com/snapcore/snapd/pull/3896) which will definitely go into 2.28. Sorry for the trouble!
Since most of the polkit work is merged, is there any chance of getting this pushed up to 2.28? It’d be nice to have it ready in time for the Ubuntu 17.10 release, and most of the supporting work has already been landed.
From what I can see, the only remaining question is about the granularity of the polkit action IDs. I think it would be fine to go with things as is if we documented that we might separate out some behaviours into extra action IDs in the future. The vast majority of users are going to be using the policy defaults though, so it is unlikely that this will be an issue.
Confirmed, polkit changes are now in 2.28.
The beta channel got updated to 2.28~rc3 - this includes the polkit from. Thanks to @jamesh for making this happen!
@mvo and @zyga-snapd: it looks like 2.28 regressed regarding udev tagging. I verified today that udev tagging is working correctly in 2.27.6
With 2.28, if I create a snap that connects the opengl interface, I expected to see a file created in /etc/udev/rules.d/70-snap.$SNAPNAME.rules on install (classic distro), but it is not created. If I disconnect and connect it is also not created. Interestingly, if I connect the uhid interface the file is created (but it has its own problems, see below).
diffing opengl.go and uhid.go there is nothing that jumps out as being a problem in opengl.go. If I update interfaces/udev/backend.go Setup() in line 95 to have:
logger.Debugf("JAMIE: snippet=%v", snippet)
then I see in the logs this:
Sep 18 17:20:59 sec-xenial-amd64 snapd[11846]: 2017/09/18 17:20:59.302199 backend.go:69: DEBUG: JAMIE: snippet=
snippet is always empty. There are quite a few levels of indirection to disentangle wrt spec, etc that I didn’t have time to do before EOD, so reporting here in the hopes it is obvious to @zyga-snapd or someone else what the problem is.
The snap I am using is: https://code.launchpad.net/~jdstrand/+git/test-policy-app
Regarding uhid, it looks like it doesn’t have entries in sysfs, so it isn’t getting properly udev tagged. This is a separate issue that needs to be addressed. Perhaps in the same manner I worked around nvidia: https://github.com/snapcore/snapd/pull/3938
Actually, I was working out of master, not the 2.28 branch and assumed 2.28 was affected (in case someone looks at this).
I was not able to reproduce this here with both the release/2.28 nor the master branch. I did the following:
In both cases I got a file that looks like this:
# This file is automatically generated.
KERNEL=="sr[0-9]*", TAG+="snap_test-policy-app_optical-drive"
KERNEL=="scd[0-9]*", TAG+="snap_test-policy-app_optical-drive"
SUBSYSTEM=="drm", KERNEL=="card[0-9]*", TAG+="snap_test-policy-app_opengl"
KERNEL=="nvidia*", TAG+="snap_test-policy-app_opengl"
KERNEL=="vchiq", TAG+="snap_test-policy-app_opengl"
Do you have any hints what I’m missing?
Yesterday, I used dpkg-buildpackage and installed on 16.04 amd64 classic distro.
Today I tried:
snap refresh core --edge in amd64 Ubuntu Core vmThe deb was built in a xenial amd64 schroot with:
$ dch -i # set version to 2.28~jdstrand1 to avoid reexec
$ DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -uc -us
Then I scp’d the resulting binary (../snapd_2.28~jdstrand1_amd64.deb) to the vms, installed and rebooted. Then I ‘snap install hello-world’ before installing test-policy-app with --dangerous.
So, I guess everything is fine. @mvo, sorry for the noise. This is not the first time things didn’t work as expected, but I can’t seem to figure out why. Clearly I am messing something up.
@jdstrand It might be something local in a bad environment, but it might also be some unusual combination of facts that trigger a problem we’d like to see fixed, so thanks for the report, and please keep an eye on it.
I certainly plan to. The fact I don’t know why I saw the issue is bugging me. 
Hello, the 2.28.1 release is on the candidate channel. Please help testing by snap refresh --candidate core and let us know if everything works as expected.
Please, let me know if you find any regression.
Can we please make sure the distro check refactor PR is merged and cherry picked into 2.28? This is necessary for fixing problems related to derivative distributions using snapd in the RH/Fedora ecosystem.