[03:18] PR snapcraft#1958 opened: Migrating to more granular store permission [06:10] morning [06:38] PR snapd#4733 closed: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos [06:42] PR snapd#4732 closed: [2.31] timeutil: account for 24h wrap when flattening clock spans [06:42] PR snapd#4734 closed: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos - 2.31 [06:42] PR snapd#4736 closed: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos - 2.32 [06:50] PR snapd#4713 closed: cmd/snap: add self-strace to `snap run` [06:50] hey mborzecki ! good morning [06:51] mvo: hey, morning [06:51] mvo: is it also that cold where you live? [06:51] mborzecki: yeah, unusually cold. up to minus 10 or so in the nights [06:52] mborzecki: very clear skys all the time, sunny but bitter cold :) [06:52] mvo: my outside thermometer is showing -14 atm [06:52] mvo: yeah, it's clear and sunny.. and cold :P [06:53] mborzecki: woah, -14 even [06:53] impressive! [06:53] my dogs were unimpressed this morning :) [06:53] heh [06:54] * mvo checks his outside thermometer [07:08] PR snapd#4739 opened: many: remove snapd.refresh.{timer,service} [07:15] good morning [07:15] hey zyga ! good morning [07:16] hey [07:16] mvo I experienced something very odd last nigth [07:16] 54 Do 2018-02-24T10:49:28Z - Auto-refresh snap "core" [07:16] my snapd is stuck updating [07:17] I sent a pastebin as well, still valid: https://pastebin.ubuntu.com/p/sj6s9qNzFQ/ [07:17] and I had one denial [07:17] lut 25 22:08:15 fyke kernel: audit: type=1400 audit(1519592895.774:1751): apparmor="DENIED" operation="exec" profile="/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snap-device-helper" pid=39793 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 [07:17] I'm currently on core 16-2.29.4.2 4144 canonical core [07:18] I wonder if this is some bad revision that didn't have the symlink to make it work [07:18] or if we missed something bigger [07:18] and release will break [07:18] oh, and none of the snaps work now [07:19] they fail with that same denial [07:19] PR snapd#4737 closed: cmd/snap: tweaks to 'snap info' (feat. installed->current rename) [07:20] looking at snapd.service logs I see one more error: [07:20] lut 24 11:49:38 fyke snapd[35097]: 2018/02/24 11:49:38.755234 backend.go:91: cannot create host `snap userd` dbus service file: failed to copy all: "cp: nie [07:21] and that's all [07:21] ideas welcome, I'm not sure what's failed [07:22] for instance, I don't understand why the change is stuck [07:22] why is it not auto-connecting things [07:22] deadlock? [07:35] zyga: uh, thats serious if that is stable to stable [07:36] zyga: yeah, its very strange. 2.29 you say? its double strange as it should also have tried to go to 2.30 before already [07:37] I think something odd has happened [07:37] it is on distro package now [07:38] I didn't set any reexec flags [07:38] nothing in /etc/environment [07:38] any ideas on what to check for next? [07:38] note: I installed a snap on Friday evening [07:43] mvo how can I be on 4144 which is more recent than beta but less recent than core [07:43] and still be on 2.29.4.2?!? [07:43] is. that some build that was made to make an out-of-bounds release [07:43] this makes no sense to me [07:53] zyga: what channel are you tracking? [07:54] edge [07:54] zyga: and what does "apt list --all snapd" show? [07:54] zyga: edge, huh [07:54] Name Version Rev Developer Notes [07:54] core 16-2.31+git583.0e8bcef 4104 canonical core,disabled [07:54] core 16-2.31+git586.d89ba3c 4117 canonical core,disabled [07:54] core 16-2.31.1+git587.d3e52a0 4133 canonical core,disabled [07:54] core 16-2.29.4.2 4144 canonical core [07:55] zyga: apt :) [07:55] given this revision progression [07:55] haha [07:55] zyga: you mentioned your packaged version is run [07:55] I didn't see apt [07:55] I replaced "snapd" with core without thinking though [07:55] yeah [07:55] because of the +17.10 version [07:55] zyga@fyke:~/go/src/github.com/snapcore/snapd$ snap version [07:55] snap 2.29.4.2+17.10 [07:55] snapd 2.29.4.2+17.10 [07:56] mvo is it sane that 4144 has version 16-2.29.4.2? [07:57] zyga: no, that does not sound sensible [07:57] can you pull that revision and check? [07:57] zyga: what does snap changes show? is it maybe trying to refresh for some time wihtout success? [07:57] ID Status Spawn Ready Summary [07:57] 54 Do 2018-02-24T10:49:28Z - Auto-refresh snap "core" [07:57] 55 Done 2018-02-26T00:51:39Z 2018-02-26T00:51:39Z Refresh all snaps: no updates [07:57] I pastebinned snap change 54 earlier [07:58] zyga: and before that? when was the last successful core update? [07:58] that 55 is "fun" because there *are* updates but core has changes in progress [07:58] there's nothing more, is there a switch for earlier history? [07:58] zyga: uh, you are right: 4144 2018-02-24T04:25:30Z amd64 16-2.29.4.2 edge [08:00] zyga: so it looks like on sat we had 2.29.4.2 in edge for a brief time before a new build kicked in [08:00] zyga: and we got the git version again [08:00] store bug? [08:00] zyga: so you went from master (from friday) to 2.29.4.2 and then back to git and that seems to be not working [08:01] zyga: I think more a problem with the snap-cron publish to edge thing [08:03] zyga: what does `snap version` give you? [08:03] zyga: i.e. which version is active right now? [08:03] zyga: (sorry if you said this already) [08:03] 2.29.4.2 [08:03] since all other versions are deactivated [08:03] good morning! [08:04] well [08:04] 2.29.4.2+17.10 [08:04] so that is the vanilla packaged version [08:04] zyga: so here is my theory: you started with 2.32~git, that generated a new auto-connect tasks, then it installed core 2.29.4.2 because of silliness, then that rebooted and tried to do the tasks that are in the state [08:04] zyga: however 2.29.4.2 does not know about auto-conneect so its stuck in doing [08:05] didn't we have an unknown task handler now? [08:05] maybe not in 2.29 [08:05] zyga: exactly, not in 2.29 [08:05] zyga: fortunately its only people tracking edge that are affected and the change will be auto-abort after 7(?) days [08:05] zyga: still not great [08:06] do we keep track of the edge publishing cron job [08:06] to ensure this was really it? [08:07] zyga: I think so, we have the spread-cron logs for vendor-sync and the ppa upload history and the core build logs [08:09] btw, off-topic: I will have some fixes to layouts [08:09] can we do another RC? [08:09] zyga: yes [08:09] this will make them work on core [08:09] excellent [08:09] I will have two or three patches [08:09] just running spread to make sure it's green before I start chopping [08:10] wow [08:10] mvo I aborted change 54 and instantly I got a change 66 that refreshed core correctly [08:10] I'm tracking edge again now [08:10] zyga: sounds good, either a 2.32 targeted PR or make the PR with as little commits as possible so that we/i/you can cherry-pick [08:11] zyga: thanks for confirming, so it will auto-heal [08:11] those will be separate for review and because they are not related; each one should be ok to cherry-pick [08:12] moin moin [08:12] hey kalikiana [08:19] woot :) [08:19] it passed :) === Tenente is now known as LtWorf [08:35] PR snapd#4740 opened: cmd/snap-update-ns: use syscall.Symlink instead of os.Symlink [08:35] mvo 1st PR: https://github.com/snapcore/snapd/pull/4740/files [08:35] PR #4740: cmd/snap-update-ns: use syscall.Symlink instead of os.Symlink [08:38] mvo 2nd PR: https://github.com/snapcore/snapd/pull/4741/files [08:38] PR #4741: cmd/snap-update-ns: use recursive bind mounts for writable mimic [08:38] once those land the spread test should pass [08:39] PR snapd#4741 opened: cmd/snap-update-ns: use recursive bind mounts for writable mimic [08:54] * zyga -> breakfast [08:59] morning! [09:00] hey [09:00] I saw your PR last night [09:01] zyga: which of 'em? [09:01] it's been a fun weekend :-) [09:02] the one on sunday night [09:02] anyway, I will go over PRs soon [09:02] but some 2.32 things first [09:10] mvo: hi, thinking a bit, in 2.32 we should probably not ask for snap_yaml_raw on snap find/store.Find [09:11] pedronis: ok, what is the alternative we should use? [09:11] mvo: ? [09:11] pedronis: we need the plugs to get the default provider [09:11] pedronis: we use snap_yaml_raw to get that data [09:11] mvo: I'm saying we should ask for details [09:11] but not find [09:12] pedronis: oh, on find? yes [09:12] pedronis: that sounds sensible [09:12] mvo: we don't use it [09:12] afaict [09:12] on find [09:12] oooh, oohh [09:12] can i work on that? [09:12] is just that fields is the same for all [09:12] :-) [09:12] atm [09:12] i've been wanting to make fields per request [09:13] Chipaca: yes, please, as I said, something we can still add to 2.32 though [09:13] 2.32 is _right now_, no? [09:13] yes [09:13] ok [09:13] but I suspect we neeld .x [09:14] (btw, if you guys haven't tried the Go (mono) font, you should) [09:14] Chipaca: yeah, please do! we are at 2.32~pre1 so as long as it can be cherry picked all is well [09:14] Hello, I'm a bit confused about something. Are the channel risks 4 (stable, candidate, beta, edge) or can there be more? [09:14] palasso: the risks are those four [09:15] https://forum.snapcraft.io/t/channels-2-0-implementation/156 [09:16] "This allow publishers to go beyond the current 4 channels we offer and provide custom channels." [09:16] palasso: risks != channels [09:16] palasso: a channel is track/risk[/branch] [09:16] So the channels go beyond in the sense of having tracks and branches? [09:16] palasso: with a default track of 'latest' [09:17] palasso: I think I've been in the 'new' channels world for too long and I don't remember well being where you are, but I'll try [09:17] palasso: we used to have just four channels, representing risk levels [09:18] palasso: what used to be just 'stable', is now fully called latest/stable [09:18] palasso: (although we'll still call it just stable, because the latest/ is implied) [09:18] palasso: and, devs can ask for more "tracks", which is the 'latest' bit [09:18] Ahh I see [09:18] palasso: if you do «snap info go» you'll see a good example [09:19] Chipaca: If an app were to have an "LTS" stable release (e.g. firefox has ESR) how would they do it under the current 4 risks model? they'd introduce an ESR/stable? [09:20] palasso: yes, or if there are going to be multiple ESRs (like Ubuntu has multiple supported LTSs), they could call it something more specific [09:20] palasso: or have both, a generic ESR that tracks the latest ESR, and a more specific ESR-x-y-z [09:21] I see, thank you :) [09:21] palasso: the mysql snap also makes good use of tracks [09:21] that's why tracks were introduced, to support parallel streams of maintained releases [09:21] Okay I'll check out go and mysql. Thank you for providing me examples as well [09:22] palasso: a bad example of a snap is if you have a commercial and a free version, you shouldn't really use tracks for one and t'other [09:22] s/bad example of a snap/bad example of a use of tracks for a snap/ [09:22] Yeah I've noticed for example how JetBrains does it [09:23] k [09:23] * Chipaca gets back to codin' [09:24] mvo: I was meant to write a forum topic before that current pr got merged [09:24] :-) [09:24] * Chipaca writes [09:25] also! mvo, pedronis, zyga, (mborzecki, pstolowski?), niemeyer, feedback appreciated on the 'debugging tab completion' tutorialish thing [09:25] Chipaca where can we read it? [09:25] https://forum.snapcraft.io/t/debugging-tab-completion/4198 [09:33] PR snapd#4730 closed: userd/tests: Test kdialog calls and mock kdialog too to make tests work in KDE [09:39] mvo: #4737 isn't going to sneak into 2.32, right? [09:39] PR #4737: cmd/snap: tweaks to 'snap info' (feat. installed->current rename) [09:39] ie it's 2.33 material, which is not for another month/ [09:39] ? [09:41] Chipaca: if there is a compelling reason we can cherry pick it [09:41] Chipaca: its still early in 2.32 [09:44] mvo: on the contrary, I want it _not_ in 2.32 [09:44] mvo: to give people more forewarning of the change [09:44] mvo: am I right in guesstimating 2.33 is a month away? [09:44] from hitting stable [09:45] or is it a month from release, and another month to stable? [09:47] zyga: pstolowski: can give #4695 another pass? [09:47] PR #4695: wrappers: generator for systemd OnCalendar schedules [09:48] yes, in a moment [09:48] great, thanks [09:49] Chipaca: it should go to beta around when 2.32 goes to stable (roadmap says mar 12), but we still have things for 18.04 that are not in 2.32, not sure how that will play on 2.33 timing [09:50] pedronis: mar12 is right after the sprint [09:50] that seems to be setting us up for insanity [09:50] let's not do that :-) [09:50] do what? [09:50] pedronis: set ourselves up for insanity [09:50] * pedronis expects Mar to be insane [09:55] mborzecki, sure, sorry i didn't do that last Fri, will do [09:57] I need two reviews for critical PRs [10:00] zyga: shout [10:00] last two open PRs [10:00] one trivial [10:00] one more complex [10:00] 4740 is trivial [10:00] PR snapd#4728 closed: store: move infoFromRemote into details.go close to snapDetails [10:08] zyga: you're going to need el jay-dee to look at 4741 i think [10:10] zyga: am I reading it right that with this change we _always_ use detach? [10:10] for directories, yes [10:10] for files we keep the regular thing [10:10] zyga: is that reasonable? [10:11] yes, as the commit message explains we have no other choice [10:11] i guess we don't record when we recursed? [10:11] no no, we always pair recurse with detach [10:11] we don't always detach [10:11] ah ok [10:11] or am I missing something [10:11] Chipaca: yeah, 2.33 is about a month away [10:11] I mean, that is the intent [10:13] zyga: https://github.com/snapcore/snapd/pull/4741/files#diff-4480ffd44957efa3395867c929f88014L377 [10:13] PR #4741: cmd/snap-update-ns: use recursive bind mounts for writable mimic [10:13] zyga: that's the bit that looked very unconditional [10:13] but i might be missing part of the logic [10:13] that's the safe keeping directory [10:13] it is originally rbind'ed [10:14] each rbind should be paired with MNT_DETACH [10:14] k [10:14] https://github.com/snapcore/snapd/pull/4741/files#diff-4480ffd44957efa3395867c929f88014L331 [10:15] heh, and pedronis agrees from backstage [10:15] 'backstage' ;) [10:15] 'bambalinas' translates as that, but it doesn't feel the same [10:15] ¯\_(ツ)_/¯ [10:15] hmm? [10:16] it's used as 'behind the scene' more than 'backstage', i guess, although those two are the same (but different) [10:16] zyga: he quietly added jdstrand as reviewer of the PR [10:16] oh I would definitely have jamie review it [10:16] stage are scenes but not all scenes are stages [10:16] I said so last week [10:17] zyga: but who listens to you [10:17] pedronis: translating is hard [10:22] PR snapd#4740 closed: cmd/snap-update-ns: use syscall.Symlink instead of os.Symlink [10:27] mvo any idea why snapd-control-with-manage consistently failed in your PR? [10:27] https://api.travis-ci.org/v3/job/346163312/log.txt [10:27] this is inside 4739 [10:28] zyga: let me check [10:29] zyga: yes, let me fix it [10:29] do you know what happened there? [10:30] zyga: yes, a leftover that checked for snapd.refresh in a test [10:31] zyga: I killed that and force pushed (for cherry-picking) [10:31] cool, thanks! [10:31] mvo: https://paste.ubuntu.com/p/4y6jghpWQz/ maybe you're missing this [10:32] mvo: I did those changes on Friday but didn't open a PR yet :) [10:32] mborzecki: yes, except for the first bit :) - echo 'from the store start/enable the snapd.service' is still needed, right? or will it be enabled (snapd.service) on arch on install? [10:32] mborzecki: if so I can kill it [10:32] mborzecki: that line [10:33] mvo: you can kill it to [10:33] mborzecki: cool [10:33] mvo: there's one peculiar scenario with the timers that I mentioned here https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239/20 [10:34] not sure if anyone uses it like this, but if you only have snapd.socket enabled, then snapd will not run unless something activates it, and if so, no refreshes will be applied [10:34] mborzecki: are you sure it can be removed? the current install says "to use snapd start/enable the snapd.socket" but that means that on the next reboot snapd will only come up after "snap list" (or similar). so to get refreshes the user still has to enable the snapd.service so that it runs persistently? or am I missing something [10:35] mvo: yes, that PKGBUILD is not used and i'll be syncing it with the one that's in the AUR repo [10:35] * Chipaca -> break (physio) [10:35] mvo: that echo was removed there as well [10:36] mborzecki: aha, I think we are on the same page. so we should keep the message about "systemctl start/enable snapd.service" ? [10:36] mvo: you can keep it for now [10:36] mborzecki: I mean, we should contribute that back to upstream (this echo?) [10:36] mborzecki: ok [10:38] zyga: pushed an update to 4695 [10:38] ack [10:39] mvo: what do you think about the case when only socket activation is enabled? [10:40] mborzecki: a good question, I think its an unsupported mode of operation, we should advice our packagers to recommend to enable the service. and if its not done, well [10:40] not much we can do - we could warn of course [10:42] PR snapd#4727 closed: many: simplify mocking of home-on-NFS [10:42] a bit crazy, but i thought we could do something like the timer services, autogenerate snapd.refresh.timer and have `snap refresh --timer='...'` [10:49] we have a bunch of extra logic around refreshes [10:50] we retry to some extent if they fail (but waiting at least some time) [10:55] pedronis: right, but it only works as long as snapd is running, whereas if you do socket activation only then it may not be running at all [10:56] mborzecki: my point is more that implementing that way add different complexity to support an unsupported mode [10:56] pedronis: aah, you're right, maybe it's not worth doing this at all [11:00] mborzecki, my comment re systemd-analyze was about making sure we run this check on predefined systems (similiar to what we do in some spread tests) and not just rely on path lookup [11:00] mborzecki, but I'm not sure how to do that nicely and if it's worth it. just 'nice to have' [11:01] otherwise we have no guarantee we run this validation at all [11:01] pstolowski: we could fail the test if systemd-analyze is not found, but that seems a bit overager [11:01] s/overager/overeager/ [11:01] mborzecki, maybe just a warning that the check was disabled? [11:05] PR snapcraft#1949 closed: repo: silence deb caching when fetching packages [11:07] pstolowski: yeah, warning will probably do [11:08] PR snapd#4742 opened: overlord/snapstate: verify that default schedule is randomized and is not a single time [11:09] so that we don't accidentally break the store again ^^ [11:12] * cachio afk [11:14] jdstrand hey, please have a look at 4714 [11:14] jdstrand I think it can land for 2.32 cherry-pick then [11:14] (though it might be a bigger pick) [11:15] jdstrand please also look at a layout bugfix in 4741 [11:15] jdstrand with that in the spread test in 4644 passes [11:19] ok, now for a tiny break and then back to mount validation [11:31] * zyga FAIL: store_asserts_test.go:161: storeSuite.TestCheckAuthority [11:31] * zyga store_asserts_test.go:180: [11:31] * zyga c.Assert(err, ErrorMatches, `store assertion "store1" is not signed by a directly trusted authority: other`) [11:31] * zyga ... error string = "store assertion timestamp outside of signing key validity (key valid since \"2018-02-26 10:45:06 +0000 UTC\")" [11:31] * zyga ... regex string = "store assertion \"store1\" is not signed by a directly trusted authority: other" [11:32] this popped up on an unrelated PR [11:32] pedronis ^ [11:32] the PR is 4739 [11:32] zyga: seen it a couple of times already [11:36] hmm the tst suite setup is using time.Now().Truncate(time.Second), while respective tests just do time.Now().Format(...) [11:37] zyga: are you updating those tests? [11:37] nope, go ahead please [11:37] I'm still trying to finish the race detector [11:47] PR snapd#4742 closed: overlord/snapstate: verify that default schedule is randomized and is not a single time [12:03] mvo: can you publish 2.31.1 release files on github? [12:11] mborzecki: sure, done [12:11] PR snapcraft#1955 closed: meta: make sure adapter does not propagate [12:11] mvo: thanks [12:17] PR snapcraft#1844 closed: Included fix for error messages [12:27] mborzecki having read https://www.freedesktop.org/software/systemd/man/systemd.time.html I really think syntax is hard [12:27] zyga: ours or theirs? [12:28]